wprintf() conflicts with printf(). glibc bug?

[steve yee]

On linux federa 10 beta, calling wprintf() following printf(),
wprintf() seems doing nothing$B!%(BAnd vice versa. Is it a glibc bug?

 

[Ben Bacarisse]

On linux federa 10 beta, calling wprintf() following printf(),
wprintf() seems doing nothing．And vice versa. Is it a glibc bug?

No. All streams may have an orientation (wide or not) but they all
start with none. The first operation will set it thereby rendering
the "other" family of functions invalid. You can test and/or set it
using the fwide function.

 

[steve yee]

No. All streams may have an orientation (wide or not) but they all
start with none. The first operation will set it thereby rendering
the "other" family of functions invalid. You can test and/or set it
using the fwide function.

Yes. The fwide() can set an orientation. But it the orientation can
not be changed once set. While on AIX printf() and wprintf() do not
interfere with each other.

 

[Ben Bacarisse]

Best not to quote sigs.

Yes. The fwide() can set an orientation. But it the orientation can
not be changed once set.

That is true. If an implementation permits such a change, it does so
as an extension and a portable program should avoid relying on it.

While on AIX printf() and wprintf() do not
interfere with each other.

Then that is a perfectly legal extension. Section 7.19.2 paragraph 5
says (in part):

"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."

The "shall not" phrase means that doing so results in undefined
behaviour. An implementation can do what it likes in such cases. A
programmer should try to avoid them!