This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |