It is my absolute expectation that dyld_stub_NSLog follows C argument evaluation semantics. However, the argument evaluation time of the format string being passed to NSLog is not the time when the description methods are called. They are called from within the NSLog function. dyld_stub_NSLog is a function in the Objective-C runtime and could easily check the run-time stack and discover another call to itself higher in the chain and simply return. However, as I stated, I only know the results, not the true cause.
On Dec 20, 2009, at 3:50 AM, Tom Davie wrote:
> I'm sorry, but you're explanation does not make sense in a C like language setting.
> A C like language uses eval/apply semantics – i.e. a function's arguments are evaluated before the function is applied. With this in mind, the arguments to NSLog are evaluated in an environment that knows nothing about them being arguments, let alone what they're arguments to.
> It appears that NSLog does not allow "recursive" calls, that is, if you call NSLog and the evaluation of one of its arguments ALSO causes calls NSLog, the deeper calls are essentially ignored. I don't know how to prove this definitively but it is the case that the deeper calls to NSLog do indeed call dyld_stub_NSLog, but instead of dyld_stub_NSLog doing anything real, it returns immediately.
> (I had NSLog calls inside a class's description method; these calls did not work when the description method was called within the context of another NSLog. However, when the description method is called outside the context of an NSLog call the NSlog calls in the description method work fine.)
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden