[Top][All Lists]

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

Re: NSLog() / NSLogv() annoyance

From: Adam Fedor
Subject: Re: NSLog() / NSLogv() annoyance
Date: Fri, 1 Aug 2003 08:55:29 -0600

On Friday, August 1, 2003, at 08:46 AM, Richard Frith-Macdonald wrote:

On Friday, August 1, 2003, at 03:33 PM, Adam Fedor wrote:

On Friday, August 1, 2003, at 12:10 AM, Richard Frith-Macdonald wrote:

So NSLog should back-up the original? It's kind-of crazy, but probably the best solution, since there are a lot of places where gnustep-base uses c-library functions (we don't want to have to change all of them), and NSLog is probably the only place where the developer would expect errno to be the same before and after the >> call.

Sorry to come in so late to this ... I've been away from home on business ...

In unix, the value of errno is conventionally (and I think perhaps explicitly) undefined except for immediately after executing a system call which failed (or after a library
function which is explicitly documented to set errno).

So tracking down exactly why something within NSLog() sets errno a particular way seem of dubious benefit, since any code which relies on testing errno after the call to NSLog() is by definition buggy in that it is depending on undefined behavior.

Is there anything I've missed in this thread to give a reason why NSLog() should behave differently from all other functions and methods? Perhaps this is a documented Apple
behavior or something?

The only thing is that you might want to do something like call some library function and if there was an error, print it out, like:

file = fopen("/dev", "w");
if (file == NULL)
  NSLog(@"Got an error opening /dev, errno = %d", errno);

GNUstep will (more than likely) print out the wrong error number, since there are hidden library calls in NSLog, MacOSX will print out the correct value. I'm not sure if you should rely on this being correct though.

I know you know this but ... it's easy to overlook when you are used to working with objects ... in C/ObjC, function arguments are passed by value rather than by reference.

This means that if (the value of) errno is passed as an argument to NSLog, the value logged will be the original value passed irrespective of any changes to the contents of the errno
variable which might be made inside NSLog itsself.
Any other behavior is a compiler bug.

Yes, I tried to simplify my example too much... Anyway, it seems like it shouldn't be an issue in a well written program.

reply via email to

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