This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Wednesday 05 September 2012 20:55:36 Joseph S. Myers wrote: > On Wed, 5 Sep 2012, Mike Frysinger wrote: > > uClibc has some documentation/references to examples of glibc ignoring > > some standards related cases. i think some bugs were filed (and then > > closed), but some might have just been on the mailing list. > > If you (or anyone else) know of bugs you think were wrongly closed, please > reopen them if still applicable (making sure they contain a testcase that > still fails, and that there isn't another bug already open for the issue > in question). As far as I'm concerned we should fix such bugs, and track > them in Bugzilla until they are fixed. this is the list that uClibc carries. i don't have access to C99 standards to see what it has to say exactly, or to compare against newer ones, so i'll just dump here. if people are aware of some of these still being applicable, we can move the issue into a bug. or if they're aware of some as being obsolete, we can quickly toss them. posts from "Manuel Novoa III" here: http://sources.redhat.com/ml/libc-alpha/2003-09/ which probably overlap with this list: 1) The C99 standard says that for printf, a %s conversion makes no special provisions for multibyte characters. SUSv3 is even more clear, stating that bytes are written and a specified precision is in bytes. Yet glibc treats the arg as a multibyte string when a precision is specified and not otherwise. 2) Both C99 and C89 state that the %c conversion for scanf reads the exact number of bytes specified by the optional field width (or 1 if not specified). uClibc complies with the standard. There is an argument that perhaps the specified width should be treated as an upper bound, based on some historical use. However, such behavior should be mentioned in the Conformance document. 3) glibc's scanf is broken regarding some numeric patterns. Some invalid strings are accepted as valid ("0x.p", "1e", digit grouped strings). In spite of my posting examples clearly illustrating the bugs, they remain unacknowledged by the glibc developers. 4) glibc's scanf seems to require a 'p' exponent for hexadecimal float strings. According to the standard, this is optional. 5) C99 requires that once an EOF is encountered, the stream should be treated as if at end-of-file even if more data becomes available. Further reading can be attempted by clearing the EOF flag though, via clearerr() or a file positioning function. For details concerning the original change, see Defect Report #141. glibc is currently non-compliant, and the developers did not comment when I asked for their official position on this issue. 6) glibc's collation routines and/or localedef are broken regarding implicit and explicit UNDEFINED rules. -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |