Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 1 Sep 2010 00:32:01 +0200 (CEST)
From:      Gerald Pfeifer <gerald@pfeifer.com>
To:        FreeBSD-gnats-submit@FreeBSD.org
Subject:   amd64/150170: SIG_ATOMIC_MIN/SIG_ATOMIC_MAX 32-bit when sig_atomic_t is 64-bit
Message-ID:  <201008312232.o7VMW1MX028335@sputnik1.dbai.tuwien.ac.at>
Resent-Message-ID: <201008312300.o7VN0DA0006337@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help

>Number:         150170
>Category:       amd64
>Synopsis:       SIG_ATOMIC_MIN/SIG_ATOMIC_MAX 32-bit when sig_atomic_t is 64-bit
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-amd64
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Aug 31 23:00:13 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator:     Gerald Pfeifer
>Release:        FreeBSD 8.0-CURRENT amd64
>Organization:
>Environment:
System: FreeBSD ref9-amd64.freebsd.org 9.0-CURRENT FreeBSD 9.0-CURRENT #4 r208973: Thu Jun 10 08:49:43 UTC 2010     simon@ref9-amd64.freebsd.org:/scratch/obj/usr/src/sys/REF9-AMD64  amd64
>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.

>How-To-Repeat:

	Run GCC's C testsuite and notice a number of C conformance tests
	around stdint fail:

FAIL: gcc.dg/c99-stdint-1.c (test for excess errors)
FAIL: gcc.dg/c99-stdint-2.c (test for excess errors)
FAIL: gcc.dg/c99-stdint-5.c (test for excess errors)
FAIL: gcc.dg/c99-stdint-6.c (test for excess errors)

>Fix:
	Initially I thought we may want to adjust SIG_ATOMIC_MIN and
	SIG_ATOMIC_MAX, but really, who need sig_atomic_t to be 64-bit?
	(Linux does not, for what it's worth.)

	In any case, having a type that is larger than the values it can
	take like this is something we should be able to avoid.  At a
	minimum it's inconsistent.
>Release-Note:
>Audit-Trail:
>Unformatted:



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201008312232.o7VMW1MX028335>