This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: Dangerous glibc byte/wide stream interactions
- To: linux-utf8 at nl dot linux dot org
- Subject: Re: Dangerous glibc byte/wide stream interactions
- From: Bruno Haible <haible at ilog dot fr>
- Date: Fri, 22 Sep 2000 14:09:50 +0200 (CEST)
- Cc: libc-alpha at sources dot redhat dot com
- References: <E13cQnC-00037v-00@wisbech.cl.cam.ac.uk>
Markus Kuhn writes:
> I admit that this behaviour does not strictly violate the letter of the
> ISO C99 standard, which says in section 7.19.2
>
> ---------------------------------------------------------------------
> [#4] Each stream has an orientation. After a stream is
> associated with an external file, but before any operations
> are performed on it, the stream is without orientation.
> Once a wide character input/output function has been applied
> to a stream without orientation, the stream becomes a wide-
> oriented stream. Similarly, once a byte input/output
> function has been applied to a stream without orientation,
> the stream becomes a byte-oriented stream. Only a call to
> the freopen function or the fwide function can otherwise
> alter the orientation of a stream. (A successful call to
> freopen removes any orientation.)224)
>
> [#5] Byte input/output functions shall not be applied to a
> wide-oriented stream and wide character input/output
> functions shall not be applied to a byte-oriented stream.
> ---------------------------------------------------------------------
>
> and which also requires neither the fwide() function nor the freopen
> function to be successful.
Right. This is also the reason why the fwide(3) manual page says:
Once a stream has an orientation, it cannot be changed and
persists until the stream is closed.
> However, I strongly argue that this behaviour makes the entire wide
> I/O system practically completely useless
It is not as useless as you might have hoped. I find fprintf with the
%lc (for a wint_t) and %ls (for a wchar_t*) directives more useful
than using fwprintf.
Some small programs can make use of wprintf, though; 'col' and 'ul',
contained in the util-linux, are examples.
> A typical program contains library modules from various sources, some of
> which will use byte-output (printf) and others will use wide-output
> (wprintf). It is *essential* that all modules can independently and
> reliably access stderr in order to issue diagnostic, warning and error
> messages.
Then they should all agree on one. Mixing printf and wprintf for the
same stream is unportable.
Bruno