Path: utzoo!attcan!uunet!husc6!cmcl2!nrl-cmf!ames!oliveb!Ozona!chase From: chase@Ozona.orc.olivetti.com (David Chase) Newsgroups: comp.lang.c Subject: Re: Insecure hardware (was Re: gets(3) nonsense) Message-ID: <33420@oliveb.olivetti.com> Date: 28 Nov 88 18:54:46 GMT References: <867@cernvax.UUCP> <645@quintus.UUCP> <339@igor.Rational.COM> <4869@bsu-cs.UUCP> <14733@mimsy.UUCP> <1189@cps3xx.UUCP> Sender: news@oliveb.olivetti.com Reply-To: chase@Ozona.UUCP (David Chase) Organization: Olivetti Research Center, Menlo Park, CA Lines: 25 In article <1189@cps3xx.UUCP> rang@cpswh.cps.msu.edu (Anton Rang) writes: > The problem lies with >the implementation of BSD and Ultrix, which leave the stack >executable; I can't see any reason for this offhand. Well, I'm told that there's signal handling code that writes on the stack and then executes it. It's also a handy trick for implementing partial application, which can in turn be used to implement lexical binding of variables in nested functions for languages that aren't C but wish to remain compatible with it. This is VERY useful if your intermediate/portability language IS C (no, I can't use a global variable to simulate a lexical or display pointer, because we'll be using threads. Yes, I'm aware that C structure-returning conventions are often non-reentrant, and we've dealt with that.) Some Lisp systems may generate code onto the stack in certain situations. Some new machines have separate instruction and data busses and/or caches, and this is sometimes given as a good reason for keeping instruction and data spaces separate (protect us from undefined results, I assume). I'd prefer otherwise, since it isn't too hard to write code to do the right thing (somewhat efficiently, even) if there is a system call that allows page-by-page changing of protection or copying of a page of data into I-space. David