discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [BUG report] NSLog on Windows!!


From: Richard Frith-Macdonald
Subject: Re: [BUG report] NSLog on Windows!!
Date: Wed, 30 Nov 2005 06:11:42 +0000


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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]