[numero]

I am taking an intro to C class. In class today the prof. talked about allocating space for an array with MALLOC. He went on to explain that the space is made in the heap and not in the reserved program space (stack). He warned us that since you are dealing with the *address* of the location of the array you must be careful not to try to read and especially write to an index greater than what was allocated or you would be stepping on someone else's toes.

This class is taught as a class on C and not for any specific platform, but the lab is stocked with PC's and that is what the instructors seem to have their background in. I asked if this memory addressing flaw was also true for unix systems. I was told it was. This doesn't seem to make sense given the emphasis placed on all of the recent buzz words, with "protected memory" being one of them.

What's the truth here? Will unix/OS X let an application access anything outside of where it should be accessing?

[BLAZE_MkIV]

Just because protected memory stops you from stepping on another programs toes doesn't mean you can't step on your own.

[numero]

So the OS (the ones with protected memory) will keep your app from getting into others, but it won't protect bad programmers from themselves?

[MachoManRandySavage]

Originally posted by numero:

What's the truth here? Will unix/OS X let an application access anything outside of where it should be accessing?

Well, from my experience, if you're using UNIX and you decide to read/write to/from memory that is outside that allocated to your program, you will get something called a "segmentation fault" and then a "core dump".

A segmentation fault generally means you've tried to read/write to memory that doesn't belong to your program (not allocated to you)

A core dump is a dump of your memory to a file called a "core file." In this file is a dump of memory at the time your caused the segmentation fault. (you can have core dumps for other reasons though too) This file is great to use if you want to find out exactly where you made your error and can be looked at with a debugger. (like gdb)

The Macintosh, however, does not have protected memory which means you can go ahead and read and write memory all over the place (inside or outside memory allocated for your program) with no problems. I'm no macos expert, though, and this is my guess. Any MacOS experts out there want to back me up/correct me on this?

Hope this helps,

The Macho Man

[Paul Crawford]

Hi all,

As The Macho Man indicated above, the Memory Manager (MM) API in Mac OS Classic (9.x, 8.x and earlier) doesn't offer memory protection. Apple has mentioned this unfortunate shortcoming in various Tech Notes of years gone by, and again more recently in the 'Chapter 6—Programming Model' of their Intro to Mac Programming online manual. The MM was primarily intended to be a heap zone manager, not a full-fledged memory management subkernel. (Perhaps the early System designers felt that the latter would be overkill in the context of a cooperatively-multitasking OS.) Although, if memory serves me correctly, Apple did make some efforts to address this issue in Systems 7.1.x - 7.5.x (when they switched from the 68K to the PowerPC architecture), and also later on with the various Mac OS 8.x versions. At least, they tried to enhance the detection of certain memory-related errors so that they could be caught with an 'Error of Type n has occurred' dialogue, instead of hard-crashing the entire machine.

In any event, the forthcoming official release of Mac OS X (non-Classic environment) will of course offer memory protection, since its core consists of BSD Unix and a Mach kernel. This approach is quite similar to the NextStep/OpenStep architecture of Jobs' former NeXT company (and it's also vaguely reminiscent of that other Apple flirtation with Unix, viz., the old A/UX which used to be bundled mainly with their Server systems). In theory, even the emulated Classic environment will be walled off from the rest of Mac OS X proper [much as MS had done with the "Windows on Windows (WOW)" Win16-emulation layer in Win32]; although, within that emulation environment itself, a Classic app or extension will probably be able to blithely stomp on other Classic apps as usual [which will no doubt satisfy our pangs of nostalgia for the bad old days ;-)].

Regards,

--Paul

[This message has been edited by Paul Crawford (edited 03-07-2001).]