Harald Alvestrand wrote on 2000-09-24 21:19 UTC:
> the behaviour of a (badly behaved) library calling fprintf() on stderr when
> an unexpected error happens and the calling program has already used
> fwritnf() is not going to be obvious enough to notice.
>
> a check (if mode != rightmode {die with snide comment}) would seem
> appropriate, have moderate execution time impact, and would possibly reduce
> the amount of hair loss in C programmers.
It now seems that the most severe aspect of the behaviour that I
observed was caused by a bug in glibc's wide output functions that
Ulrich fixed yesterday. This bug distorted output to stderr even without
anyone switching between wide and byte streams.
With this fixed, I hope that at least as long as one does an fflush()
between a byte and a wide output function, nothing really bad will
happen (this still has to be tested though!). Then, things shouldn't be
really as bad in practice as I had feared originally, especially as long
stderr is unbuffered or at least only line buffered.
General comment:
I urge you all to install the very latest CVS snapshot of glibc,
start playing around with the wide character I/O functions and the
multi-byte/UTF-8 locales, and report any strange observations to
<[EMAIL PROTECTED]>. Instructions for installing glibc
under Linux are available on
http://clisp.cons.org/~haible/glibc22-HOWTO.htm
I found quite a number of severe problems within just a few hours of
testing this weekend. If the wide and multi-byte support is not
sufficiently mature when the first glibc 2.2 release enters a major
Linux distribution, then this can easily delay the common acceptability
of using glibc's Unicode support for over two years. So *please* help to
test it thoroughly before glibc becomes called 2.2.0.
Markus
--
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/lists/
