Re: Encoding infinite loops
Re: Encoding infinite loops
- Subject: Re: Encoding infinite loops
- From: Chris Kane <email@hidden>
- Date: Tue, 22 May 2007 16:05:40 -0700
On May 22, 2007, at 14:06 PM, Uli Kusterer wrote:
On 22.05.2007, at 17:32, Chris Kane wrote:
I think you may have missed the point of the problem. Here's a
different way to view it: the unarchiver has no way to go back and
replace all the pointers to an object that it has already given
out, when an object is replaced later. The unarchiver could
provide a mechanism, but every unarchivable class has to also
participate in order to handle potential updates, which is where
things fall apart -- the unarchiver can't mandate such
participation (for backwards compatibility, for example).
Ah, OK. That makes more sense. Still, I'd expect this would be a
situation that can be detected and can at least show an error, can't
it?
With additional memory/data structures and checking in various places,
yes. At least, I think there exists an implementation which does not
have any issues with potential pointer reuse for different objects.
It's not a direct problem (as far as the unarchiver is concerned) to
give out pointers to an object which is still being initialized, so
the check can't be done there, though that would be easy. The
archiver already knows what objects are currently being initialized up
the call stack and knows when it gives one out. Giving out the
pointer to a half-initialized object happens all the time and has to
be allowed for backwards compatibility. No, the archiver would have
to keep track of whether, for each call to initWithCoder:, that
original object was given out during that method invocation, and
complain only if a different object is returned and it original had
been given out. It could then, say, throw an exception.
However, detecting this only when the document is later loaded (and
having the attempt fail) does not seem very satisfying. The user
saved their document and can't reopen it. But, the archiver, while it
knows when recursion occurs, can't detect this situation (not all
recursion is evil). I suppose you could say, though, that the
developer would presumably discover this problem in writing/testing
their app, before the situation gets to the end user.
Chris Kane
Cocoa Frameworks, Apple
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden