"C" character set (again)

[Thomas Wolff]

Eric Blake wrote:
> According to Thomas Wolff on 1/8/2010 7:40 AM:
>   
>> While Andy had a valid point in finding *format* to be described as a
>> "character string" and relating that to a generic POSIX definition of
>> character,
>> this certainly does not justify the current behaviour of slient dropping
>> and reporting partial success because that is not one of the options in
>> the "RETURN VALUE" section;
>> also I don't see what Andy's claim "Including invalid bytes in the
>> format string is undefined behaviour." is based on.
>>     
Part of my point was to work this out more precisely, so please let me 
stir around once more:
> Per POSIX, printf is only defined if you pass a valid character string as the format.
Based on what? The manpage lists a number of cases of "results are 
undefined" explicitly (e.g. insufficient arguments) but the case of an 
invalid character in the format string is *not* among them, unless you 
would account the EILSEQ clause to that aim, which I wouldn't because 
the format string is not a wide character string.
So for this reasoning, you could only base on deduction of general 
descriptions (using the word "character") in relation to generic 
definitions (somewhere else in POSIX).
This is a weaker point, however, and not in line with the general 
tendency of POSIX to describe the API clearly.
And it has to be viewed in contrast with sections "RETURN VALUE" and 
"ERRORS" which *are* described clearly.
So *if* one could arguably sustain the view that invalid multi-byte 
characters in the format wouldn't need to be handled transparently,
it would be mandatory for printf to return -1 in that case and set 
errno=EILSEQ.

> If you pass an 8-bit value but it is not a character, then
> you did not pass a valid format string.
That may be the case (I'm almost convinced meanwhile by Andy and you) 
but yet... see above, it doesn't mean "completely undefined".

> That's why your behavior was undefined, and so ANYTHING can happen 
No, not quite anything, APIs are not pure maths, Return Value conditions 
still have to be met.

> ...
>
> My opinion is that it would still be nice to keep "C" in the UTF-8 charset
> (to encourage people to fix their programs that do not comply with POSIX
> rules about the C locale), but to fix 8-bit transparency issues in as many
> APIs as possible (such as printf) so that invalid characters are at least
> still handled as transparently-clean 8-bit bytes.
Yes, please.

> In the long run,
> sticking with the UTF-8 charset will only be doing users a favor, even if
> we end up having to point people to the FAQ about locale implications.
>   
With this, I fully agree.

------
Thomas