From owner-freebsd-standards@FreeBSD.ORG Mon Dec 29 11:07:03 2008 Return-Path: Delivered-To: freebsd-standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D8B91065677 for ; Mon, 29 Dec 2008 11:07:03 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E70928FC16 for ; Mon, 29 Dec 2008 11:07:02 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mBTB72E2024596 for ; Mon, 29 Dec 2008 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mBTB72s0024592 for freebsd-standards@FreeBSD.org; Mon, 29 Dec 2008 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 29 Dec 2008 11:07:02 GMT Message-Id: <200812291107.mBTB72s0024592@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-standards@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-standards@FreeBSD.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2008 11:07:03 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o stand/129554 standards lp(1) [patch] Implement -m and -t options o stand/129524 standards FreeBSD 7.0 isnt detecting my hardrives with raid5 o stand/128546 standards ls -p does not follow symlinks o bin/125855 standards sh(1) allows for multiline, non-escaped control struct o stand/124860 standards flockfile(3) doesn't work when the memory has been exh o stand/123688 standards POSIX standard changes in unistd.h and grp.h o stand/121921 standards [patch] Add leap second support to at(1), atrun(8) o stand/121568 standards [patch] ln(1): wrong "ln -s" behaviour o stand/120947 standards xsm ignores system.xsm and .xsmstartup o stand/119804 standards [timedef] [patch] Invalid (long)date format in pl_PL.I o stand/118047 standards SUGGESTION: /etc/printcap vs mergemaster o stand/116826 standards [PATCH] sh support for POSIX character classes o stand/116477 standards rm(1): rm behaves unexpectedly when using -r and relat o bin/116413 standards incorrect getconf(1) handling of unsigned constants gi o stand/116081 standards make does not work with the directive sinclude o kern/114578 standards [libc] wide character printing using swprintf(dst, n, p stand/107561 standards [libc] [patch] [request] Missing SUS function tcgetsid o stand/104743 standards [headers] [patch] Wrong values for _POSIX_ minimal lim o stand/100017 standards [Patch] Add fuser(1) functionality to fstat(1) o stand/96236 standards [PATCH] [POSIX] sed.1 incorrectly describes a function o stand/96016 standards [headers] clock_getres et al should be in o stand/94729 standards [libc] fcntl() throws undocumented ENOTTY o kern/93705 standards [headers] [patch] ENODATA and EGREGIOUS (for glibc com o stand/92362 standards [headers] [patch] Missing SIGPOLL in kernel headers a stand/86484 standards [PATCH] mkfifo(1) uses wrong permissions o stand/83845 standards [libm] [patch] add log2() and log2f() support for libm o stand/82654 standards C99 long double math functions are missing o stand/81287 standards [PATCH]: fingerd(8) might send a line not ending in CR a stand/80293 standards sysconf() does not support well-defined unistd values o stand/79056 standards [feature request] [atch] regex(3) regression tests o stand/72006 standards floating point formating in non-C locales o stand/70813 standards [PATCH] ls(1) not Posix compliant o stand/66357 standards make POSIX conformance problem ('sh -e' & '+' command- s kern/64875 standards [libc] [patch] [request] add a system call: fdatasync( s stand/62858 standards malloc(0) not C99 compliant o stand/56476 standards cd9660 unicode support simple hack p stand/55112 standards glob.h, glob_t's gl_pathc should be "size_t", not "int o stand/54839 standards [pcvt] pcvt deficits o stand/54833 standards [pcvt] more pcvt deficits o stand/54410 standards one-true-awk not POSIX compliant (no extended REs) o stand/46119 standards Priority problems for SCHED_OTHER using pthreads o stand/44425 standards getcwd() succeeds even if current dir has perm 000. p stand/41576 standards POSIX compliance of ln(1) o stand/39256 standards snprintf/vsnprintf aren't POSIX-conformant for strings s stand/36076 standards Implementation of POSIX fuser command o kern/27835 standards [libc] execve() doesn't conform to execve(2) spec in s a docs/26003 standards getgroups(2) lists NGROUPS_MAX but not syslimits.h o stand/25777 standards [kernel] [patch] atime not updated on exec o bin/25542 standards sh(1) null char in quoted string s stand/24590 standards timezone function not compatible witn Single Unix Spec o bin/24390 standards ln(1) Replacing old dir-symlinks when using /bin/ln o stand/21519 standards sys/dir.h should be deprecated some more s bin/14925 standards getsubopt isn't poisonous enough 53 problems total. From owner-freebsd-standards@FreeBSD.ORG Tue Dec 30 16:10:04 2008 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9F301065750 for ; Tue, 30 Dec 2008 16:10:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4E6CD8FC0C for ; Tue, 30 Dec 2008 16:10:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mBUGA3Tf096109 for ; Tue, 30 Dec 2008 16:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mBUGA3Ph096108; Tue, 30 Dec 2008 16:10:03 GMT (envelope-from gnats) Date: Tue, 30 Dec 2008 16:10:03 GMT Message-Id: <200812301610.mBUGA3Ph096108@freefall.freebsd.org> To: freebsd-standards@FreeBSD.org From: Bruce Cran Cc: Subject: Re: standards/62858: malloc(0) not C99 compliant X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bruce Cran List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2008 16:10:06 -0000 The following reply was made to PR standards/62858; it has been noted by GNATS. From: Bruce Cran To: bug-followup@FreeBSD.org,stefan@fafoe.narf.at, phk@freebsd.org Cc: Subject: Re: standards/62858: malloc(0) not C99 compliant Date: Tue, 30 Dec 2008 16:06:21 +0000 It appears that with jemalloc in 7.0 onwards, the behaviour has changed and is now C99 compliant: malloc(0) returns a unique pointer that increments by 2 bytes each time. -- Bruce Cran From owner-freebsd-standards@FreeBSD.ORG Tue Dec 30 22:40:01 2008 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB2CF1065677 for ; Tue, 30 Dec 2008 22:40:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8558C8FC19 for ; Tue, 30 Dec 2008 22:40:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mBUMe1wJ009427 for ; Tue, 30 Dec 2008 22:40:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mBUMe1rr009426; Tue, 30 Dec 2008 22:40:01 GMT (envelope-from gnats) Resent-Date: Tue, 30 Dec 2008 22:40:01 GMT Resent-Message-Id: <200812302240.mBUMe1rr009426@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-standards@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Vaclav Haisman Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0E001065670 for ; Tue, 30 Dec 2008 22:31:30 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id AF5DD8FC12 for ; Tue, 30 Dec 2008 22:31:30 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id mBUMVURC092911 for ; Tue, 30 Dec 2008 22:31:30 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id mBUMVUtf092910; Tue, 30 Dec 2008 22:31:30 GMT (envelope-from nobody) Message-Id: <200812302231.mBUMVUtf092910@www.freebsd.org> Date: Tue, 30 Dec 2008 22:31:30 GMT From: Vaclav Haisman To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: standards/130067: Wrong numeric limits in system headers? X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2008 22:40:02 -0000 >Number: 130067 >Category: standards >Synopsis: Wrong numeric limits in system headers? >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-standards >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Dec 30 22:40:01 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Vaclav Haisman >Release: 6.3 >Organization: SU SH >Environment: FreeBSD shell.sh.cvut.cz 6.3-PRERELEASE FreeBSD 6.3-PRERELEASE #0: Fri Jan 18 17:04:16 CET 2008 root@shell.sh.cvut.cz:/usr/obj/usr/src/sys/SHELL-SMP i386 >Description: There seems to be a problem with definition of long double limits on FreeBSD i386/6.x. shell::wilx:~/packed_vector> echo | g++ -dD -E - | sort | grep LDBL_MAX #define __LDBL_MAX_10_EXP__ 4932 #define __LDBL_MAX_EXP__ 16384 #define __LDBL_MAX__ 1.1897314953572316e+4932L shell::wilx:~/packed_vector> fgrep -rn LDBL_MAX /usr/include [...] /usr/include/machine/float.h:75:#define LDBL_MAX_EXP 16384 /usr/include/machine/float.h:76:#define LDBL_MAX 1.1897314953572317650E+4932L /usr/include/machine/float.h:77:#define LDBL_MAX_10_EXP 4932 /usr/include/float.h:75:#define LDBL_MAX_EXP 16384 /usr/include/float.h:76:#define LDBL_MAX 1.1897314953572317650E+4932L /usr/include/float.h:77:#define LDBL_MAX_10_EXP 4932 Notice the difference in definition of LDBL_MAX, the values in system headers are tiny bit larger than that defined by GCC itself. machine/float.h:76:#define LDBL_MAX 1.1897314953572317650E+4932L float.h:76:#define LDBL_MAX 1.1897314953572317650E+4932L GCC: __LDBL_MAX__ 1.1897314953572316e+4932L A simple test shows the following: shell::wilx:~/tmp> cat >longdouble.cxx #include #include #include int main () { typedef std::numeric_limits limits; std::cout << "max: " << limits::max () << "\n"; std::cout << "__LDBL_MAX__: " << __LDBL_MAX__ << "\n"; std::cout << "LDBL_MAX: " << LDBL_MAX << "\n"; } shell::wilx:~/tmp> g++ -o longdouble longdouble.cxx shell::wilx:~/tmp> ./longdouble max: 1.18973e+4932 __LDBL_MAX__: 1.18973e+4932 LDBL_MAX: inf This is on 6.3/i386. 7.1/AMD64 does not print inf for LDBL_MAX. I think this is a bug in 6.x headers or in GCC 3.4.x that it uses. LDBL_MAX should never result in "inf". >How-To-Repeat: #include #include #include int main () { typedef std::numeric_limits limits; std::cout << "max: " << limits::max () << "\n"; std::cout << "__LDBL_MAX__: " << __LDBL_MAX__ << "\n"; std::cout << "LDBL_MAX: " << LDBL_MAX << "\n"; } >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-standards@FreeBSD.ORG Wed Dec 31 13:09:01 2008 Return-Path: Delivered-To: freebsd-standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CF76106564A; Wed, 31 Dec 2008 13:09:01 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx10.syd.optusnet.com.au (fallbackmx10.syd.optusnet.com.au [211.29.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id 202A48FC21; Wed, 31 Dec 2008 13:08:54 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by fallbackmx10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id mBVBQVN9016490; Wed, 31 Dec 2008 22:26:31 +1100 Received: from c211-30-173-239.carlnfd1.nsw.optusnet.com.au (c211-30-173-239.carlnfd1.nsw.optusnet.com.au [211.30.173.239]) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id mBVBQMgX014574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 22:26:26 +1100 Date: Wed, 31 Dec 2008 22:26:22 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Vaclav Haisman In-Reply-To: <200812302231.mBUMVUtf092910@www.freebsd.org> Message-ID: <20081231215445.S3923@delplex.bde.org> References: <200812302231.mBUMVUtf092910@www.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: imp@FreeBSD.org, freebsd-gnats-submit@FreeBSD.org, freebsd-standards@FreeBSD.org Subject: Re: standards/130067: Wrong numeric limits in system headers? X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2008 13:09:01 -0000 On Tue, 30 Dec 2008, Vaclav Haisman wrote: > There seems to be a problem with definition of long double limits on FreeBSD i386/6.x. > > shell::wilx:~/packed_vector> echo | g++ -dD -E - | sort | grep LDBL_MAX > #define __LDBL_MAX_10_EXP__ 4932 > #define __LDBL_MAX_EXP__ 16384 > #define __LDBL_MAX__ 1.1897314953572316e+4932L > > shell::wilx:~/packed_vector> fgrep -rn LDBL_MAX /usr/include > [...] > /usr/include/machine/float.h:75:#define LDBL_MAX_EXP 16384 > /usr/include/machine/float.h:76:#define LDBL_MAX 1.1897314953572317650E+4932L > /usr/include/machine/float.h:77:#define LDBL_MAX_10_EXP 4932 > /usr/include/float.h:75:#define LDBL_MAX_EXP 16384 > /usr/include/float.h:76:#define LDBL_MAX 1.1897314953572317650E+4932L > /usr/include/float.h:77:#define LDBL_MAX_10_EXP 4932 > > Notice the difference in definition of LDBL_MAX, the values in system > headers are tiny bit larger than that defined by GCC itself. > ... > machine/float.h:76:#define LDBL_MAX 1.1897314953572317650E+4932L > float.h:76:#define LDBL_MAX 1.1897314953572317650E+4932L > GCC: __LDBL_MAX__ 1.1897314953572316e+4932L This has never worked. However, since gcc became aware of the limited precision of long doubles under FreeBSD a few years ago, it shouldn't be as broken as it is. Gcc defines __LDBL_MAX__ to have the correct value (1-2^-53)*2^1024 (rounded to 17 digits, which is enough for the actual precision of 53 bits), while FreeBSD defines LDBL_MAX as (1-2^-64)*2^1024 (rounded to 20 digits, which is perhaps not quite enough for the non-actual precision of 64 bits (either this 20 or DECIMAL_DIG's value of 21 is dubious). The wrong value in FreeBSD may have worked accidentally a few years ago, but now hit has no chance of working: - a few years ago: gcc didn't know about FreeBSD's limited precision, so it evaluated the constant in 64-bit precision and got precisely (1-2^-64)*2^1024 (only the decimal constant is imprecise). Static initialization to this value preserved the value. Actual use of the value caused it to be rounded to 53 bits. I think that still made it Infinity in most cases. - now: gcc evaluates it in 53-bit precision and gets Infinity for it consistently. Many other long double constants in FreeBSD's have never worked, and are much further from neing correct, but are fixed in gcc: >From gcc4.2 -E -dM: % #define __LDBL_MAX__ 1.1897314953572316e+4932L % #define __LDBL_MAX_EXP__ 16384 % #define __LDBL_HAS_INFINITY__ 1 % #define __LDBL_MIN__ 3.3621031431120935e-4932L % #define __LDBL_HAS_QUIET_NAN__ 1 % #define __LDBL_HAS_DENORM__ 1 % #define __LDBL_EPSILON__ 2.2204460492503131e-16L % #define __LDBL_DIG__ 15 % #define __LDBL_MANT_DIG__ 53 % #define __LDBL_MIN_EXP__ (-16381) % #define __LDBL_MAX_10_EXP__ 4932 % #define __LDBL_DENORM_MIN__ 7.4653686412953080e-4948L % #define __LDBL_MIN_10_EXP__ (-4931) >From float.h: % #define LDBL_MANT_DIG 64 Wrong; should be 53. All the other errors are derived from this (see the definitions of FLT_* for the derivations -- p must be 53 but is 64). % #define LDBL_EPSILON 1.0842021724855044340E-19L Wrong: too small by a factor of 2^13. % #define LDBL_DIG 18 Wrong: unnecessarily large (fairly harmless). % #define LDBL_MIN_EXP (-16381) Correct. % #define LDBL_MIN 3.3621031431120935063E-4932L Correct (just has more precision than needed for rounding to 53 bits). % #define LDBL_MIN_10_EXP (-4931) % #define LDBL_MAX_EXP 16384 Correct. % #define LDBL_MAX 1.1897314953572317650E+4932L Wrong: see above. % #define LDBL_MAX_10_EXP 4932 Correct. Bruce From owner-freebsd-standards@FreeBSD.ORG Wed Dec 31 13:10:03 2008 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50122106564A for ; Wed, 31 Dec 2008 13:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3C5058FC17 for ; Wed, 31 Dec 2008 13:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mBVDA2DW004097 for ; Wed, 31 Dec 2008 13:10:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mBVDA21N004096; Wed, 31 Dec 2008 13:10:02 GMT (envelope-from gnats) Date: Wed, 31 Dec 2008 13:10:02 GMT Message-Id: <200812311310.mBVDA21N004096@freefall.freebsd.org> To: freebsd-standards@FreeBSD.org From: Bruce Evans Cc: Subject: Re: standards/130067: Wrong numeric limits in system headers? X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bruce Evans List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2008 13:10:03 -0000 The following reply was made to PR standards/130067; it has been noted by GNATS. From: Bruce Evans To: Vaclav Haisman Cc: freebsd-gnats-submit@FreeBSD.org, freebsd-standards@FreeBSD.org, imp@FreeBSD.org Subject: Re: standards/130067: Wrong numeric limits in system headers? Date: Wed, 31 Dec 2008 22:26:22 +1100 (EST) On Tue, 30 Dec 2008, Vaclav Haisman wrote: > There seems to be a problem with definition of long double limits on FreeBSD i386/6.x. > > shell::wilx:~/packed_vector> echo | g++ -dD -E - | sort | grep LDBL_MAX > #define __LDBL_MAX_10_EXP__ 4932 > #define __LDBL_MAX_EXP__ 16384 > #define __LDBL_MAX__ 1.1897314953572316e+4932L > > shell::wilx:~/packed_vector> fgrep -rn LDBL_MAX /usr/include > [...] > /usr/include/machine/float.h:75:#define LDBL_MAX_EXP 16384 > /usr/include/machine/float.h:76:#define LDBL_MAX 1.1897314953572317650E+4932L > /usr/include/machine/float.h:77:#define LDBL_MAX_10_EXP 4932 > /usr/include/float.h:75:#define LDBL_MAX_EXP 16384 > /usr/include/float.h:76:#define LDBL_MAX 1.1897314953572317650E+4932L > /usr/include/float.h:77:#define LDBL_MAX_10_EXP 4932 > > Notice the difference in definition of LDBL_MAX, the values in system > headers are tiny bit larger than that defined by GCC itself. > ... > machine/float.h:76:#define LDBL_MAX 1.1897314953572317650E+4932L > float.h:76:#define LDBL_MAX 1.1897314953572317650E+4932L > GCC: __LDBL_MAX__ 1.1897314953572316e+4932L This has never worked. However, since gcc became aware of the limited precision of long doubles under FreeBSD a few years ago, it shouldn't be as broken as it is. Gcc defines __LDBL_MAX__ to have the correct value (1-2^-53)*2^1024 (rounded to 17 digits, which is enough for the actual precision of 53 bits), while FreeBSD defines LDBL_MAX as (1-2^-64)*2^1024 (rounded to 20 digits, which is perhaps not quite enough for the non-actual precision of 64 bits (either this 20 or DECIMAL_DIG's value of 21 is dubious). The wrong value in FreeBSD may have worked accidentally a few years ago, but now hit has no chance of working: - a few years ago: gcc didn't know about FreeBSD's limited precision, so it evaluated the constant in 64-bit precision and got precisely (1-2^-64)*2^1024 (only the decimal constant is imprecise). Static initialization to this value preserved the value. Actual use of the value caused it to be rounded to 53 bits. I think that still made it Infinity in most cases. - now: gcc evaluates it in 53-bit precision and gets Infinity for it consistently. Many other long double constants in FreeBSD's have never worked, and are much further from neing correct, but are fixed in gcc: From gcc4.2 -E -dM: % #define __LDBL_MAX__ 1.1897314953572316e+4932L % #define __LDBL_MAX_EXP__ 16384 % #define __LDBL_HAS_INFINITY__ 1 % #define __LDBL_MIN__ 3.3621031431120935e-4932L % #define __LDBL_HAS_QUIET_NAN__ 1 % #define __LDBL_HAS_DENORM__ 1 % #define __LDBL_EPSILON__ 2.2204460492503131e-16L % #define __LDBL_DIG__ 15 % #define __LDBL_MANT_DIG__ 53 % #define __LDBL_MIN_EXP__ (-16381) % #define __LDBL_MAX_10_EXP__ 4932 % #define __LDBL_DENORM_MIN__ 7.4653686412953080e-4948L % #define __LDBL_MIN_10_EXP__ (-4931) From float.h: % #define LDBL_MANT_DIG 64 Wrong; should be 53. All the other errors are derived from this (see the definitions of FLT_* for the derivations -- p must be 53 but is 64). % #define LDBL_EPSILON 1.0842021724855044340E-19L Wrong: too small by a factor of 2^13. % #define LDBL_DIG 18 Wrong: unnecessarily large (fairly harmless). % #define LDBL_MIN_EXP (-16381) Correct. % #define LDBL_MIN 3.3621031431120935063E-4932L Correct (just has more precision than needed for rounding to 53 bits). % #define LDBL_MIN_10_EXP (-4931) % #define LDBL_MAX_EXP 16384 Correct. % #define LDBL_MAX 1.1897314953572317650E+4932L Wrong: see above. % #define LDBL_MAX_10_EXP 4932 Correct. Bruce