Erland Sommarskog <sommar(_at_)algonet(_dot_)se> writes:
I have to admit that I have not completely researched what the documentation
has to say, but this is not only a question on how, but also on which way
to take.
I'm working on an XS module that will interact with the SQL Server OLE DB
Provider, thus it will run on Windows only. The intention is that the
XS will be wrapped in a Perl module, and the data will end up in Perl
variables. Also for error messages from SQL Server, the intention is that
normally there will be a callback to a Perl routine that will print the
messages. But there are situations that I plan to print messages directly
from the XS module, and these message can include data that comes from
SQLOLEDB, and thus be Unicode.
The problem I see is that I don't know in which output mode Perl_IO_stderr()
has been opened in. Should I query PeriIO about the mode and then convert
the data to the proper encoding, or is possible to pass some PerlIO print
function an SV, and then let PerlIO do the job?
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.
Even perl can't guess what that is reliably, it just assumes it is
iso-8859-1 and "downgrades" to that.
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...
