Nick Ing-Simmons (nick(_at_)ing-simmons(_dot_)net) writes:
As far as you are concerned PerlIO_stderr() is either ready to accept
UTF-8 when you don't have a problem, (other than UTF-8 encoding chars)
or it is "still" in native mode - presumably some code page or other.
Or it has been set to utf16-le or whatever!
Even perl can't guess what that is reliably, it just assumes it is
iso-8859-1 and "downgrades" to that.
Not really sure what you mean, I would expect that PerlIO internally
knows what is up to. But whether there is a supported API where I can
retrieve this I don't know.
Of course, if I say
PerlIO_printf(PerkIO_stderr(), "%s\n", variable)
Perl cannot make a guess on whether variable is in the same charset or
not as PerlIO is targetted for, but must take the bits as is. (And
barf, if stderr is in UTF-8 and the string is malformed UTF-8.) So I
would have to be responsible for converting to the right decoding.
Surely it is not a good
thing to bypass PerlIO completely, and use wprintf or somesuch?
That should not be too bad on stderr (as it is unbuffered) but it isn't
a good thing...
Thanks for the slight encouragement in this direction. I'll see what I
do. As I said, this is not a big deal, since in most cases the error
messages should go through a callback routine in Perl.
--
Erland Sommarskog, Stockholm, sommar(_at_)algonet(_dot_)se
