guy@gorodish.UUCP (06/11/87)
> trying to access the new memory, then if a segmentation fault happens, > allocate by moving the break forward and trying again. Pretty poor > programming practice. > > I don't see why. In some contexts, it's an OK programming practice. I can testify, however, that it's not an OK programming practice in this context: 1) Not all systems will restart or continue a faulting instruction when a SIGSEGV handler returns: a) The system might not permit instructions to be restarted or continued, in general. (68000) Those systems often have the compiler generate an instruction in the procedure prolog that touches the end of the stack; either this instruction is one that can be continued or restarted, or the kernel can handle a fault in this instruction as a special case. One can't necessarily do this in the more general case of the Bourne shell's "stack" handling. b) The system might permit instructions to be restarted or continued, but the technique used may involve a large amount of stuff dumped onto the stack. This stuff may be in a format that the hardware manufacturer does not document, and the manufacturer may also not give any guarantee that arbitrary tampering with this data will be detected and will not cause Evil Things to happen. (68010, 68020). These systems will either have to checksum this data, put it somewhere in the address space not writable by the user, temporarily write-protect the area where it is placed and play some tricks to ensure that the user can modify other sections of this area but can't modify this stuff, do the same trick but keep an unmodified copy of the data, or pull some other such trick - or pray. All of these involve some additional complication. 2) It doesn't seem to buy you anything. We had to fix the Bourne shell here not to do that, because we fall into category b) above and don't bother playing the tricks described - we just don't let you continue instructions when returning from a SIGSEGV handler. Those fixes were applied to an otherwise vanilla S5R2 shell, and both the vanilla and modified S5R2 shells were built on a 3B2 here (the 3B2 does, I believe, permit you to return from a SIGSEGV handler). I tried running something like echo `cat *.c` or something like that, in the hopes of testing the performance impact of removing the SIGSEGV hack. I saw no performance difference between the two versions of the shell in this case. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
gwyn@brl-smoke.UUCP (06/14/87)
In article <20870@sun.uucp> guy%gorodish@Sun.COM (Guy Harris) writes: > Those fixes were applied to an otherwise vanilla S5R2 shell, For some time now the BRL Bourne shell has had what are essentially Guy's fixes in place, and they work just fine. We're nearly finished with a significantly improved release (with many other portability problems fixed) that will be announced in UNIX-WIZARDS when it's ready. Please wait for the announcement before sending in your request.