Re^2: Using sigvec & sigcontext

[Chris Torek]

>>In article <4549 at freja.diku.dk> seindal at skinfaxe.diku.dk (Rene' Seindal)
wrote:
>>>On 4.3BSD on Vaxen, the struct sigcontext has the same contents as a
>>>``jmp_buf'' (??),

>to which I said
>>Not so:

In article <4557 at freja.diku.dk> seindal at skinfaxe.diku.dk (Rene' Seindal)
replies:
>I said same contents, not same type.

Ah: I misinterpreted.

>[setjmp] uses [only] the first seven longwords of the jmp_buf....

Indeed it does.

>jmp_buf is probably only declared as an array, so people don't have
>to take the address themselves.

Historically, jmp_buf has always been an array; and according to the
pANS for C, it must be so.  In fact the array was once used to hold
r6 through r15 (in the days of 4.1BSD), and its size is a holdover.

But the two are not interchangeable, aside from an accident of
implementation (well, of design, in this case).  It is reasonable for
setjmp and longjmp to want to preserve more state than a sigcontext
(register contents, for instance, on 680x0s, where the call frame does
not let you restore registers by unwinding).  Sticking with jmp_bufs
for longjmp and sigcontexts for signals is much safer.

>Syscall 139 still exists in the 4.3 I use (MORE/bsd) ...
(and in 4.3tahoe)
>Was it left in only because of longjmp() ... or because other
>programs depended on it ... ? 

It was left in for backwards compatibility.  4.3BSD-tahoe will still
run most 4.1BSD binaries.  (Exceptions are things using the jobs
library, and things using vread and/or vwrite.  There may be others.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris