Re: Weird error with structs and @try/@catch
Re: Weird error with structs and @try/@catch
- Subject: Re: Weird error with structs and @try/@catch
- From: "Michael Ash" <email@hidden>
- Date: Thu, 11 May 2006 12:30:30 -0400
Sorry Uli, you'll get this twice since I messed up and only sent it to
you the first time
On 5/11/06, Uli Kusterer <email@hidden> wrote:
Though I feel kinda bad just casting away volatile-ness. Anyone
remember what that did and why it's safe to just cast it away?
It's required because ObjC exceptions, even the fancy new @ ones, are
based on setjmp/longjmp. This means that when you throw an exception,
any values that were stored in registers get blown away and replaced
with the register contents that were around at the point when you
entered the exception handler. Using volatile forces the compiler to
store each change to memory. Consider the following code:
int x = 5;
@try {
x = 6;
@throw @"exception";
}
@catch(id obj) {
NSLog(@"x = %d", x);
}
Without volatile, as would happen if you used the old NS_DURING
constructs, I believe it's possible for it to print "x = 5", since if
x happened to be in a register at the time then it would get
overwritten with its old contents, but I can't actually make this
happen when trying a little test program.
So, long story short, using the newer constructs the compiler will
automatically insert the volatile qualifier when necessary, but this
does occasionally mess things up in other ways.
Since volatileness never matters when you're making a copy, only when
taking a pointer, it's completely harmless to cast it away here. (I
assume it matters when you're making a copy of fancy C++ objects
somewhere, since the compiler is trying to stop you, but it won't
matter for boring structs.)
Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden