From owner-freebsd-hackers  Sat Nov 18 21:34:44 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id VAA14228
          for hackers-outgoing; Sat, 18 Nov 1995 21:34:44 -0800
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA14216
          for <hackers@FreeBSD.org>; Sat, 18 Nov 1995 21:34:33 -0800
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id QAA20802; Sun, 19 Nov 1995 16:29:36 +1100
Date: Sun, 19 Nov 1995 16:29:36 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199511190529.QAA20802@godzilla.zeta.org.au>
To: cimaxp1!jb@werple.net.au, hackers@FreeBSD.org, julian@ref.tfs.com
Subject: Re: int type in jmpbuf
Cc: jb@cimlogic.com.au
Sender: owner-hackers@FreeBSD.org
Precedence: bulk

>Shouldn't jmp_buf and sigjmp_buf (in /usr/include/setjmp.h) be defined as an
>array of long type (instead of int)?

>NetBSD _needs_ it that way to support 64 bit addressing. I'm uncomfortable
>porting code which is already both 32 and 64 bit clean to be 64 bit unclean!

>(Assuming that long _should_ be used) Can we change this for 2.2 please?

The whole struct should probably be delcared in a machine dependent file
as something like

typedef struct {
	__type_whose_alignment_requirement_i_maximal_t _jb0;
	char _jb1[_NOT_QUITE_THE_FULL_SIZEOF_JMP_BUF];
} jmp_buf[1];

longs just happen to be right for a few more machine than ints.

Bruce