Re: [BUG report] NSLog on Windows!!

[Richard Frith-Macdonald]

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.