wpintf()与printf()的冲突

==========================================

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

==============================================

steve yee

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

Ben Bacarisse

steve yee <yitonglu@gmail.comwrites:

On linux federa 10 beta, calling wprintf() following printf(),
wprintf() seems doing nothing. 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

On Nov 10, 8:24 pm, Ben Bacarisse <ben.use...@bsb.me.ukwrote:

steve yee <yiton...@gmail.comwrites:

On linux federa 10 beta, calling wprintf() following printf(),
wprintf() seems doing nothing$B!%(BAnd 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.

--
Ben.

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

steve yee <yitonglu@gmail.comwrites:

On Nov 10, 8:24 pm, Ben Bacarisse <ben.use...@bsb.me.ukwrote:

>steve yee <yiton...@gmail.comwrites:

On linux federa 10 beta, calling wprintf() following printf(),
wprintf() seems doing nothing. 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.

--
Ben.

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!

--
Ben.

原文链接： http://bytes.com/groups/c/852681-wprintf-conflicts-printf-glibc-bug