> Well, no. 'error' is an OUTPUT ONLY pointer. Specifically, on entry: > > 1. 'error' is either NULL (no error information should be returned), or a > valid address to return a NSError* into, if an error occurs > 2. '*error' is trash (<-- subtle, but important) > > On output: > > 1. If 'error' was NULL, you of course don't try to return anything > 2. If 'error' is non-null and you return NO, '*error' must point to a valid > NSError object that you created > 3. If 'error' is non-null and you return YES, '*error' does not need to be > preserved (you can set it whatever trash you want) (<-- subtle but important) > > If I read your post correctly, you're trying to interpret '*error' as input, > which is a no-no.
No, not quite. More accurately I was assuming that error is explicitly a pointer to nil upon entry (or, I suppose, a pointer to some other valid NSError that appeared from somewhere and was handed through to us). So basically the important thing is that setting error to something (even a nil, at a minimum) is required if writeToURL:... returns NO. Which makes sense if the input pointer could be garbage. And specifically, the fix that I came up with of explicitly setting *error = nil is the proper fix. Otherwise, returning NO without explicitly setting the error parameter will result in a dangling pointer and undefined results. I still think this is a bad thing. At a minimum, I'd consider it a documentation bug where the docs need to explicitly state that you have to assign to it in some manner if you return NO. It's possible that the docs may say that somewhere regarding object pointers handed in like this in general, but I sure didn't see it in NSPersistentDocument's. I'm not that up on my pointer allocations. Is there some memory/performance reason why it isn't explicitly set to a nil first? Personally, if I'm using one of these methods that takes an NSError**, I always hand in a pointer to an explicit nil to ensure the space is wiped clean. Incidentally, it originally manifested for me because I have some fancy code to combined complex errors into a single message for display purposes so as not to display a "Multiple Validation Errors Ocurred" message. That code was what was assuming that it'd be given either a valid NSError or nil, because it's called very recursively internally elsewhere in the code. Thanks for the info this makes it much more clear. -Jim..... _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
