This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: musl - and menchmarking libc
On Wed, 26 Sep 2012, Mike Frysinger wrote:
> 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.
Bug 6530. Someone needs to test / resubmit / ping the patch / testcases
on libc-alpha.
> 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.
Bug 12701.
> 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.
Bug 12437 (and 12701) for "1e", I think; it's possible that "0x.p" is
related to 13988 (NB I haven't checked if "0x.p" is indeed still
accepted), but mentioning it in that bug would still seem a good idea.
If digit grouped strings are still accepted, whether in the C locale or
(in other locales) in cases where they are not accepted by the function to
which the definition of scanf refers (such as strtol or strtod), please
file a bug with testcases; I don't see an obvious existing open bug for
that.
> 4) glibc's scanf seems to require a 'p' exponent for hexadecimal float strings.
> According to the standard, this is optional.
Looks like this (bug 4342) was fixed by:
commit bd9be6797769ae747e28bda38fd36ca8643c4298
Author: Ulrich Drepper <drepper@redhat.com>
Date: Fri Apr 27 19:28:32 2007 +0000
(_IO_vfscanf_internal): Allow hexa-decimal floats without exponent.
> 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.
Bug 1190, being discussed lately.
> 6) glibc's collation routines and/or localedef are broken regarding implicit
> and explicit UNDEFINED rules.
No idea what is being referred to. A bug needs to be filed with more
details, if still applicable.
I advise making the uClibc list give URLs for the individual bugs being
referred to....
There's certainly room for someone to become glibc's stdio expert and work
through the open stdio bugs. I rather hoped when splitting some of the
large groups of "libc" bugs out into other components that this might
encourage people to pick up components and work through them (someone
still needs to deal with the miscellaneous bugs in "libc", though).
--
Joseph S. Myers
joseph@codesourcery.com