Re: More Mac like handling of OS raised exceptions
Re: More Mac like handling of OS raised exceptions
- Subject: Re: More Mac like handling of OS raised exceptions
- From: Scott Ellsworth <email@hidden>
- Date: Tue, 16 May 2006 13:40:47 -0700
(Posted to the list, as it looks like Lon seemed to think it was
going there. Apologies if this is incorrect.)
On May 16, 2006, at 12:40 PM, Lon Giese wrote:
What I intended was a discussion of the desirability to leverage
off of the kernels keen sense of memory space. For my purposes it
is not harmful to attempt to read from an illegal address...
Thing is, it is always an error to read or write to an illegal
address. Further, if you are getting a bad access error, you may be
trying to _write_ to an illegal address, and that most definitely is
a ticking time bomb. Until you look at the exact line of code, you
cannot know precisely whether it was a read or a write, and whether
the read came from a previous write to a valid, but incorrect, hunk
of memory.
Other languages made different assumptions - trying to write off the
end of a java array gets you a runtime exception that is a hundred
percent safe to catch.
You pay the cost for language design decisions - ObjC wanted fast
access, and for C semantics to be unchanged, and that implies (IMO)
the 'crash if you read/write outside the bounds'.
Maybe other apps that would be catastrophic... I am saying the
kernel should give the programmer the final say if an app should be
terminated for attempting to read/write from an illegal address...
And I am saying that for a C-based language (C, ObjC, C++), the
programmer is not given the final say. It is always an error to read
or write to a spot outside your allocated memory. Further, my
experience has been that reading outside your assigned block usually
comes from a write within it, but that wrote a bad address.
In other words, you did something like
char * foo = 0;
*foo = "howdy\n";
The error was the first line, but the crash is in the second.
Since the expensive hardware is already built in (the kernel is
simply reporting an error detected by hardware) to detect most
kinds of wrongful memory access why not leverage off that instead
of writing slow and expensive code that duplicates the same
functionality being done in fast hardware ?
The hardware is not that fast - systems that attempted to use
vm_allocs for all local variable accesses were too slow to use.
Heck, people complained bitterly about the speed of early Java
releases because of the time taken to check array element indices.
That has gotten much faster since, but the problem still remains.
More to the point, this is a language design issue. You can write a
language that gives you this choice - Java made it this way. ObjC
did not - it followed the C convention of 'let programmers smash
memory. It is fun." The benefit they got? It is fairly easy to
write an efficient C compiler - CS grad students do it all the time.
It is hard to write an efficient Java compiler and runtime - it took
Sun years to get to where the JITC was producing code arguably as
efficient as decent C.
Mac is/was/should be about choice...
I do not see that. The Mac is 'about' a lot of things, but choice is
not that high on the list.
Maybe I am not understanding that the real problem is that the
kernel cannot recover from a bad access but he is trying to
convince us that it is your app that can't recover. If that is the
case then I say make the kernel more robust. Anybody out there a
kernel expert? Is there any reason the kernel could not recover
from a bad access or be made more robust?
Sure, but then every app would pay that overhead, because you have to
check every read and write to memory to make sure it is going where
you think it should. Better, IMO, for that to be done at the
language level, as then programmers can pay the cost for the features
they want.
Scott
_______________________________________________
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