LogLog char/unicode mismatch on windows

[Christoph Macheiner <Ch...@update.com>]

in log4cxx_private.hw revision 606089, the "#define
LOG4CXX_FORCE_WIDE_CONSOLE 1" was removed. now, if this is not defined,
SystemErrWriter::write() uses fwide() to determine whether to write
wchar or char and fortunately, fwide() happens to be unimplemented in
the msvc libraries. i think in this case, LOG4CXX_FORCE_WIDE_CONSOLE
should be 1 on a UNICODE build, and 0 otherwise? (or maybe there is
another way to better handle this). for now, i just defined it again in
log4cxx_private.h.

(yes, latest svn head and log4cxx(_private).h rebuilt from *.hw)

thanks, christoph

Re: LogLog char/unicode mismatch on windows

[Curt Arnold <ca...@apache.org>]

On Jan 18, 2008, at 8:12 AM, Christoph Macheiner wrote:

> also, LogLog::emit() does not append an end-of-line anymore since  
> the last change (to SystemErrWriter). is this intended?
>
> thanks, christoph
>
> -----Original Message-----
> From: Christoph Macheiner [mailto:Christoph.Macheiner@update.com]
> Sent: Freitag, 18. Jänner 2008 14:46
> To: Log4CXX User
> Subject: LogLog char/unicode mismatch on windows
>
> in log4cxx_private.hw revision 606089, the "#define  
> LOG4CXX_FORCE_WIDE_CONSOLE 1" was removed. now, if this is not  
> defined,
> SystemErrWriter::write() uses fwide() to determine whether to write  
> wchar or char and fortunately, fwide() happens to be unimplemented  
> in the msvc libraries. i think in this case,  
> LOG4CXX_FORCE_WIDE_CONSOLE should be 1 on a UNICODE build, and 0  
> otherwise? (or maybe there is another way to better handle this).  
> for now, i just defined it again in log4cxx_private.h.
>
> (yes, latest svn head and log4cxx(_private).h rebuilt from *.hw)
>
> thanks, christoph

Sorry about that.  I think that I had intended to remove the no longer  
used LOG4CXX_HAS_WLOCALE macro and inadvertently removed the  
LOG4CXX_FORCE_WIDE_CONSOLE macro instead.  I've cleaned up and aligned  
the log4cxx_private.h.in and log4cxx_private.hw files, so hopefully  
don't get them out of sync again.

For some background on the issue see

https://issues.apache.org/jira/browse/LOGCXX-126
https://issues.apache.org/jira/browse/LOGCXX-224

Basically, VC allows you to intermix wide and byte calls to the  
console.   Other platforms don't allow intermixing, so log4cxx uses  
fwide() to follow whatever the calling app has decided to use for  
console output.  In LOGCXX-224, it seems fwide() isn't reliable on  
some Linux's and reports that the console is wide when it is  
undetermined.

RE: LogLog char/unicode mismatch on windows

[Christoph Macheiner <Ch...@update.com>]

also, LogLog::emit() does not append an end-of-line anymore since the last change (to SystemErrWriter). is this intended?

thanks, christoph 

-----Original Message-----
From: Christoph Macheiner [mailto:Christoph.Macheiner@update.com] 
Sent: Freitag, 18. Jänner 2008 14:46
To: Log4CXX User
Subject: LogLog char/unicode mismatch on windows

in log4cxx_private.hw revision 606089, the "#define LOG4CXX_FORCE_WIDE_CONSOLE 1" was removed. now, if this is not defined,
SystemErrWriter::write() uses fwide() to determine whether to write wchar or char and fortunately, fwide() happens to be unimplemented in the msvc libraries. i think in this case, LOG4CXX_FORCE_WIDE_CONSOLE should be 1 on a UNICODE build, and 0 otherwise? (or maybe there is another way to better handle this). for now, i just defined it again in log4cxx_private.h.

(yes, latest svn head and log4cxx(_private).h rebuilt from *.hw)

thanks, christoph