Re: musl - and menchmarking libc

[Mike Frysinger <vapier at gentoo dot org>]

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.