Re: Pascal Calling Convention

["Randy Brukardt" <randy@rrsoftware.com>]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccei5o233l.fsf@shell01.TheWorld.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>> 99% of the time, executing data is a bug. Why allow it by default?
>
> Ah, I didn't realize you were mainly focused on that issue.
> I agree 100% that executing data is usually a bug, and should
> be prevented by default.
>
> But you don't need segments for that.  Paging hardware can do it.
> (Well, you don't need segments in hardware.  The O.S. concocts
> something like "segments" based on paging.  And protects code.)

True enough, but I was focused primarily on the existing capabilities of the 
80386 (which is the CPU that most of the current OSes started on). This chip 
had segments with the "right" permissions, while the paging stuff had little 
permission control. (And no OS or OS extension that I know of in that time 
frame used that permission control.)

Also, I think there is a (minor) advantage to separate code and data address 
spaces, in that makes it harder still to do something that fools the OS into 
executing data. If you have no executable access to the data address space, 
there is no possible bug that would allow data execution.

In any event, this was completely obvious to me even back in the days of the 
DOS Extender. All of the DOS Extenders gave you a totally flat address 
space, but they all also had a way to get a new segment. So I had Janus/Ada 
create a stub data segment in the executable file, and the first thing the 
runtime did was create a new (full-size) data segment, moved the stack 
there, and removed all references to the writable code segment registers. 
This helped fix a lot of bugs, because wild execution trapped instantly, 
rather than running for quite a while before crashing. It's too bad I can't 
do that on Windows, because I have some problems that I've been unable to 
debug with wild code execution -- I haven't been able to identify where it 
goes wrong.

                                   Randy.