Document some glibc bugs that Ulrich Drepper refuses to acknowledge. :-(

1 files changed, 31 insertions, 1 deletions

diff --git a/docs/Glibc_vs_uClibc_Differences.txt b/docs/Glibc_vs_uClibc_Differences.txt
index dcb0d31de..63b0aaaaf 100644
--- a/docs/Glibc_vs_uClibc_Differences.txt
+++ b/docs/Glibc_vs_uClibc_Differences.txt
@@ -137,6 +137,36 @@ stdio
    take place on the stream.
 8) Right now, %m is not handled properly by printf when the format uses positional
    args.
-
+9) The FILEs created by glibc's fmemopen(), open_memstream(), and fopencookie()
+   are not capable of wide orientation.  The corresponding uClibc routines do
+   not have this limitation.
+
+glibc bugs that Ulrich Drepper has refused to acknowledge or comment on
+  ( http://sources.redhat.com/ml/libc-alpha/2003-09/ )
+-----------------------------------------------------------------------
+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.
 
 More to follow as I think of it...