Date: Mon, 6 Sep 2010 21:56:00 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: John Baldwin <jhb@FreeBSD.org> Cc: Andriy Gapon <avg@icyb.net.ua>, freebsd-amd64@FreeBSD.org, bde@FreeBSD.org Subject: Re: amd64/150170: SIG_ATOMIC_MIN/SIG_ATOMIC_MAX 32-bit when sig_atomic_t is 64-bit Message-ID: <20100906214101.S887@delplex.bde.org> In-Reply-To: <201009010817.35653.jhb@freebsd.org> References: <201009011050.o81Ao3DB072806@freefall.freebsd.org> <201009010817.35653.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 1 Sep 2010, John Baldwin wrote: > On Wednesday, September 01, 2010 6:50:03 am Andriy Gapon wrote: >> The following reply was made to PR amd64/150170; it has been noted by GNATS. >> >> From: Andriy Gapon <avg@icyb.net.ua> >> To: Gerald Pfeifer <pfeifer@sputnik1.dbai.tuwien.ac.at> >> Cc: Gerald Pfeifer <gerald@pfeifer.com>, FreeBSD-gnats-submit@FreeBSD.org >> Subject: Re: amd64/150170: SIG_ATOMIC_MIN/SIG_ATOMIC_MAX 32-bit when > sig_atomic_t >> is 64-bit >> Date: Wed, 01 Sep 2010 13:26:36 +0300 >> >> on 01/09/2010 01:32 Gerald Pfeifer said the following: > ... >> >> Description: >> > On a 9.0-CURRENT machine, amd64, we have: >> > >> > /usr/include/machine/signal.h:typedef long sig_atomic_t; >> > >> > This is 32-bit. At the same time we have: >> > >> > /usr/include/machine/_stdint.h:#define SIG_ATOMIC_MIN INT32_MIN >> > /usr/include/machine/_stdint.h:#define SIG_ATOMIC_MAX INT32_MAX >> > >> > Which is 64-bit. >> >> 32-bit vs 64-bit seems to be reversed here... > > Yes, but we should still fix this one way or another. I was surprised > recently when I found that sig_atomic_t was long on amd64. Perhaps Bruce > (cc'd) knows which way it should be fixed? Not really. It is weird that sig_atomic_t is long on all 64-bit arches, but long on only 1 32-bit (also 64-bit?) arch (arm). I would have used the smallest type that works (usually signed char), but a case can be made for using the largest type that works. C99 only requires the range of the type to be at least that of an 8-bit signed char if the type is signed or at least that of an 8-bit unsigned char if the type is unsigned. Portable programs would have problems using more than the intersection of these ranges, even (or especially) if they have ifdefs using SIG_ATOMIC_MAX/MIN. Now there might be ABI problems for changing the type, or perhaps even with changing SIG_ATOMIC_MAX/MIN since these are specified as the limits of a sig_atomic_t and ifdef tangles using them might trust this. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100906214101.S887>