Bug 959794 - par mixes byte string and wide string I/O
Summary: par mixes byte string and wide string I/O
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: par
Version: 18
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: David Levine
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-05-05 19:14 UTC by Joel Uckelman
Modified: 2013-05-16 03:03 UTC (History)
1 user (show)

Fixed In Version: par-1.52-10.fc19
Clone Of:
Environment:
Last Closed: 2013-05-15 17:28:33 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Change all remining narrow I/O functions to their wide versions (7.62 KB, patch)
2013-05-05 19:14 UTC, Joel Uckelman
no flags Details | Diff

Description Joel Uckelman 2013-05-05 19:14:42 UTC
Created attachment 743838 [details]
Change all remining narrow I/O functions to their wide versions

Description of problem:

The i18n patch applied to par 1.52 didn't change all of the stream I/O functions from the char versions to the wchar_t versions. Writing byte strings and wide strings to the same stream causes undefined behavior. When par's stdout is a terminal or a file, what we get is actually ok---but when par's stdout is a pipe, the output we get is wrong.

Demonstration:

[uckelman@scylla Par152]$ cat lorem
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec fermentum enim eget dui tempor sed fringilla erat auctor.

Phasellus porta urna mauris, in pretium lacus. Duis et purus ut velit viverra suscipit.
[uckelman@scylla Par152]$ par <lorem
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec fermentum
enim eget dui tempor sed fringilla erat auctor.

Phasellus porta urna mauris, in pretium lacus. Duis et purus ut velit
viverra suscipit.
[uckelman@scylla Par152]$ par <lorem | cat

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec fermentum
enim eget dui tempor sed fringilla erat auctor.
Phasellus porta urna mauris, in pretium lacus. Duis et purus ut velit
viverra suscipit.

What you can see here is that when the i18n-patched par writes to a pipe, the blank line which is supposed to come after the first paragraph instead comes before the first paragraph. That blank line is written to stdout using putchar(), whereas the lines of the paragraph are written using fwprintf().

The attached patch changes all remaining narrow I/O functions to their wide versions. With that patch applied, we get correct results:

[uckelman@scylla Par152]$ ./par <lorem
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec fermentum
enim eget dui tempor sed fringilla erat auctor.

Phasellus porta urna mauris, in pretium lacus. Duis et purus ut velit
viverra suscipit.
[uckelman@scylla Par152]$ ./par <lorem | cat
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec fermentum
enim eget dui tempor sed fringilla erat auctor.

Phasellus porta urna mauris, in pretium lacus. Duis et purus ut velit
viverra suscipit.


Version-Release number of selected component (if applicable):

par-1.52-8.fc18.x86_64


How reproducible:

Always.

Steps to Reproduce:
1. Pipe par output somewhere.
  
Actual results:

Inter-paragraph blank lines are written ahead of all paragraph output.

Expected results:

Inter-paragraph blank lines should be between paragraphs.

Comment 1 David Levine 2013-05-05 20:23:49 UTC
Looks good, except is there a particular reason for converting the usage message to wchar?  If not, I'd like to minimize the patch.

Thanks for providing such a complete bug report.

Comment 2 Joel Uckelman 2013-05-05 21:35:17 UTC
(In reply to comment #1)
> Looks good, except is there a particular reason for converting the usage
> message to wchar?  If not, I'd like to minimize the patch.

The only reason I had for converting the usage message was that if I hadn't, then the fputs() printing it would have been the sole remaining narrow I/O function call in the whole program. I didn't want to leave one of those behind to trip up the next guy, just in case there's a change in the future which causes some wide output to be written to stderr before the usage message is written.

(The version message just above it already uses fputws() instead of fputs(), even though the whole message is ASCII, so there's nothing compelling that, either.)

> Thanks for providing such a complete bug report.

Glad I could help.

Comment 3 Fedora Update System 2013-05-06 13:48:38 UTC
par-1.52-10.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/par-1.52-10.fc19

Comment 4 Fedora Update System 2013-05-06 14:01:38 UTC
par-1.52-10.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/par-1.52-10.fc18

Comment 5 Fedora Update System 2013-05-06 18:31:40 UTC
Package par-1.52-10.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing par-1.52-10.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-7491/par-1.52-10.fc19
then log in and leave karma (feedback).

Comment 6 Fedora Update System 2013-05-15 17:28:33 UTC
par-1.52-10.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 7 Fedora Update System 2013-05-16 03:03:10 UTC
par-1.52-10.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.