reopening fprintf I18N issue

[Mark Brown]

U-

Gary Miller and I have been going over the issue you present in 
	http://www.cygnus.com/~drepper/printf.html

We believe that you have misinterpreted the ISO C specification in one
place (fprintf) and are understandably upset over the muddled definition
for fwprintf(), which will require Austin Group work to straighten out.

[For the record, Gary's first response (that glibc is currently correct and
the test suite was wrong) was based on a misreading of the question you asked).

On to the case:
> This is the result of a run of runtest.sh in the printf subdir with the 
> ja_JP.eucJP locale. You have to use the most recent CVS version of glibc
> to reproduce it. Please let me comment on the failures reported and 
> explain why I think these are errors in the test suite.
> 
> [ OK ] printf(???%s???,??) sys[????????] =  exp[????????]
> ...[cut]....
> [FAIL] printf([%-6.1s],??????) 
>     sys[[<SPC><SPC><SPC><SPC><SPC><SPC>]] != exp[[<SPC><SPC><SPC><SPC><SPC>]]
> 
> The outputs agree that nothing from the input string is printed since this 
> would mean printing an incomplete character. But the expected result is not
> providing what the format specifier says: a string padded to length 6. 
> Note that the ISO C standard is talking about characters, which is wrong and
> dangerous. The rational is clarifying this by saying these are byte counts.

This is an incorrect interpretation. The printf() class of functions is always
_byte_based_; a char is a byte in ISO C. Note that there is no "l" (ell)
qualifier present (SUSv2), thus the argument to %s is to be a pointer to an 
array of char (ISO C) -- this is because it is going to be treated as bytes. 
Note the "if precision....that many bytes are written" sentence.

As to what is going on in the test results, let me add something:

[FAIL] printf([%-6.1s],??????) 
    sys[[<SPC><SPC><SPC><SPC><SPC><SPC>]] != exp[[<SPC><SPC><SPC><SPC><SPC>]]
                                                  ^
                                                   There should be an
                                                   undisplayable single byte
                                                   here if you look at the
                                                   actual output!

Thus, 6 bytes are indeed output, fulfilling the precision and the requirements
of ISO C. The test suite should be expecting the single byte, if written
properly.


> [ OK ] printf([%-6.2s],??????) 
>     sys[[?<SPC><SPC><SPC><SPC>]] =  exp[[?<SPC><SPC><SPC><SPC>]]
> [FAIL] printf([%-6.3s],??????) 
>     sys[[?<SPC><SPC><SPC><SPC>]] != exp[[?<SPC><SPC><SPC>]]
                                            ^
                                            a single byte here as well.

etc.

Now, onward to the swprintf() issue. Gary thinks the spec here is horribly
muddled, and that both the test and glibc are doing the wrong thing. We are
going to submit an aardvark to Austin Group on this. For what it is worth,
glibc is closer the Gary's expected behavior.

Mark Brown
-- 
Mark S. Brown                                                   bmark@us.ibm.com
Senior Technical Staff Member                          512.838.3926  T/L678.3926
IBM RS/6000 AIX System Architecture                        Mark Brown/Austin/IBM
IBM Corporation, Austin, Texas