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