On 30 Nov 2005, at 01:57, Lloyd Dupont wrote:
Sorry, it's me again, made a new "discovery"
In fact there is a bug in NSLog.m: 147
if ((GSUserDefaultsFlag(GSLogSyslog) == YES
|| write(_NSLogDescriptor, buf, len) != (int)len) && !
IsDebuggerPresent())
why is it OR (||) shouldn't it be AND (&&)
certainly if the user disable GSLogSyslog it's bug to ignore his
setting, isn't it?
That code is supposed to b saying ...
if the user has asked to log to the event log (GSLogSyslog is YES) OR an
attempt to write to stderr fails (return value of the write is not the
number of characters we asked it to write) then write to the event log.
You could restructure the code as ...
BOOL shouldWriteToEventLog = NO;
if (GSUserDefaultsFlag(GSLogSyslog) == YES)
{
shouldWriteToEventLog = YES; // default says we should write to event
log
}
else if (write(_NSLogDescriptor, buf, len) != (int)len)
{
shouldWriteToEventLog = YES; // write failed ... we should write to
event log
}
if (!IsDebuggerPresent())
{
shouldWriteToEventLog = NO; // can't write to event log
}
So ... I think something unexpected is going on ... you could try
checking what GSUserDefaultsFlag() and write() are actually returning,
then figure out why.
One thing comes to mind .... perhaps the return value of the write is not
the length ... I recall that you can open files on windows in a mode
where it does strange things with end-of-line character sequences
(converting lf to crlf or some such) and I don't know if this can cause
it to report having written a different number of characters to what it
was supposed to write.