Nick Ing-Simmons ([EMAIL PROTECTED]) 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, [EMAIL PROTECTED]
