Email List: Xaustin-review-lX
[All Lists]

Defect in XCU printf

To: yyyyyyyyyyyyyyy@xxxxxxxxxxxxx
Subject: Defect in XCU printf
From: yyyy@xxxxxxx
Date: Tue, 10 Jan 2006 05:00:26 GMT
        Defect report from : Eric Blake , N/A

(Please direct followup comments direct to yyyyyyyyyyyyyy@xxxxxxxxxxxxx)

@ page 742-746 line 28936 section printf objection [ebb.printf]

Problem:

Edition of Specification (Year): 2004

Defect code :  1. Error

There is a conflict between the printf(1) specification and the File Format 
Notation that it includes by reference, in XCU pg 743 line 28936.  XBD pg 112 
line 3536 states that the '%c' sequence in a file format notation means that 
'The integer argument shall be converted to an unsigned char and the resulting 
byte shall be written.'  But printf requires, XBD pg 744 line 28976, that 'The 
argument operands shall be treated as strings if the corresponding conversion 
specifier is b,
28977 c, or s', with no further information on how %c is to be treated.

Furthermore, historical practice has been that printf treats the matching 
argument as a string, then only prints the first byte or character of that 
string (the decision depends on whether printf is locale-aware, and is 
documented in the application usage, line 29004, that printf 'makes no special 
provision for dealing with multi-byte characters when using the %c conversion 
specification').  For example, on platforms where 'A' is encoded as 65, 'printf 
%c 65' outputs '6' rather than 'A'.

However, implementations vary as to whether an empty string (either from an 
explicit '' argument in the shell, or because there are more format specifiers 
than arguments), as whether the NUL character that ends an empty string is 
printed or ignored.  But since printf documents \0 as a portable way to 
guarantee that a NUL is printed, portable applications should not need to rely 
on the behavior of 'printf %c '''.

Two wordings are proposed, based on whether it is desirable to make %c always 
print something, even if it is a NUL.

Action:

OPTION 1 - make the empty string avoid output (invalidates some existing 
implementations, but makes output predictable, and similar to %s avoiding 
output on the empty string).

Before line 28976, add a new paragraph:

11. The c conversion specifier prints the first character of its argument 
interpreted as a string; it does not take an integer argument.  If the argument 
is the empty string, nothing is printed, and no error occurs.  The behavior is 
unspecified if the first character of the string is a multi-byte character.


OPTION 2 - leave %c ambiguous in the presence of empty strings (more liberal, 
should cover all existing implementations).

Before line 28976, add a new paragraph:

11. The c conversion specifier prints the first character of its argument 
intepreted as a string; it does not take an integer argument.  If the argument 
is the empty string, it is unspecified whether the NUL character is output, or 
whether no output is produced; but no error occurs.  The behavior is 
unspecified if the first character of the string is a multi-byte character.


EITHER OPTION - the above wording does not affect the warning of line 29004.  
The remaining change applies regardless of which of the two preceeding options 
is chosen.

Before line 29040, add a new example:

The command:
printf '%c\n' 65
produces:
6
Note that the printf utility does not interpret the argument of %c as an 
integer; to output a character using an encoding, the format string should use 
an octal escape, or the format string should use the %b format specifier with 
the argument using an octal escape.

<Prev in Thread] Current Thread [Next in Thread>
  • Defect in XCU printf, ebb9 <=