Path: utzoo!utgpu!water!watmath!julian!uwovax!16012_3045
From: 16012_3045@uwovax.uwo.ca (Paul Gomme)
Newsgroups: comp.lang.c
Subject: Re: Partial application in C
Message-ID: <429@uwovax.uwo.ca>
Date: 27 Jun 88 20:42:35 GMT
References: <3353@cognos.UUCP> <619@goofy.megatest.UUCP>
Lines: 32
Organisation: University of Western Ontario, Canada

In article <619@goofy.megatest.UUCP>, djones@megatest.UUCP (Dave Jones) writes:
> 
> From article <3353@cognos.UUCP>, by jimp@cognos.uucp (Jim Patterson):
>> there are machines that don't allow you to execute data as
>> code.
> 

> 
> I began to wonder why such a restriction might be deemed necessary.
> Was it Big Brother engineering?  -- Thou shalt not modify thy
> executable, for it is a Bad Thing. -- Or is there a valid technical
> reason behind it?  I can see one possible rationale: You can have 128KB of 
> memory in a sixteen bit machine, divided evenly between data and code,
> if you use all the addresses for both kinds of memory.


	Unless my memory is failing me completely, I believe that OS/2 will
absolutely prohibit "executing data".  In fact, it does away with the
ubiquitous (MS-DOS) .COM file for the simple reason that they share code
and data segments.  My recollection is that this restriction is in place
in order to allow for "orderly" multitasking - i.e. if one process runs
amok, it shouldn't affect the other processes, which could occur if a program
can alter its code segment.
	Besides, I thought that self-modifying code was (a) extremely difficult
to write, and (b) considered poor programming practice.
-------------------------------------------------------------------------
Paul Gomme                             E-Mail:
Department of Economics
University of Western Ontario          Bitnet:  p.gomme@uwovax.bitnet
London, Ontario, Canada                         p.gomme@uwovax.uwo.ca
N6A 5B7                                ARPA:    p.gomme@uwo.ca
(519) 679-2111 ext. 6418