Subject: Re: include/setjmp.h including machine/setjmp_jblen.h ...
To: Chris G Demetriou <Chris_G_Demetriou@LAGAVULIN.PDL.CS.CMU.EDU>
From: J.T. Conklin <jtc@cygnus.com>
List: tech-kern
Date: 12/04/1994 21:40:38
>> The setjmp.h found in my NetBSD-1.0-BETA release contains a run of ...
>>
>> #if ... is an architecture ...
>> #define _JBLEN nnn
>> #elif ... a different architecure ....
>> .
>> I'd like to see this code removed, being replaced by a #include of a
>> small header file that defines _JBLEN.
Chris> also, i believe that jmp_buf (and sigjmp_buf) should be arrays of
Chris> 'long's rather than arrays of ints.
Chris> this doesn't make much difference... unless you're on a 64-bit RISC
Chris> machine that traps writes of 'long's to non-long-aligned addresses,
Chris> and which only aligns arrays of 'int's to int (i.e. 4-byte) alignment.
A jmp_buf is a opaque data structure -- it shouldn't matter what it is
defined as: an array of longs, an array of ints, an array of chars, or
some sort of structure -- as long as it can hold all the data needed
to re-create program state.
Changing the array used in the current implementation from ints to
long isn't going to make much of a difference. I'd like to know if
there are any hardware platforms that NetBSD might (realistically) be
ported to where it would make sense to declare jmp_buf in a totally
different manner? If so, why not define jmp_buf (and sigjmp_buf)
instead of _JBLEN in <machine/setjmp.h>?
--jtc