>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 si...@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: _______________________________________________ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"