summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorManuel Novoa III <mjn3@codepoet.org>2003-09-22 03:29:37 +0000
committerManuel Novoa III <mjn3@codepoet.org>2003-09-22 03:29:37 +0000
commit0511dd661021fca2d64438d6a02f3b9bba7f93c9 (patch)
tree677de8dbbd6c99325a23f820e3a90408fbcc7bfb
parent9583669237be35d9adb90e673ce7841244499d55 (diff)
Document some glibc bugs that Ulrich Drepper refuses to acknowledge. :-(
-rw-r--r--docs/Glibc_vs_uClibc_Differences.txt32
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...