From owner-freebsd-standards@FreeBSD.ORG Mon Jan 5 11:07:00 2009 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 6B6F4106564A for ; Mon, 5 Jan 2009 11:07:00 +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 4EFF28FC1F for ; Mon, 5 Jan 2009 11:07:00 +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 n05B70xQ002941 for ; Mon, 5 Jan 2009 11:07:00 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n05B6xBO002937 for freebsd-standards@FreeBSD.org; Mon, 5 Jan 2009 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 5 Jan 2009 11:06:59 GMT Message-Id: <200901051106.n05B6xBO002937@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, 05 Jan 2009 11:07:00 -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/130067 standards Wrong numeric limits in system headers? 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/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 functio 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 CRL 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 Jan 6 19:00:15 2009 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 872D1106566C for ; Tue, 6 Jan 2009 19:00:15 +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 75CEB8FC21 for ; Tue, 6 Jan 2009 19:00:15 +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 n06J0F1I073539 for ; Tue, 6 Jan 2009 19:00:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n06J0Fcl073538; Tue, 6 Jan 2009 19:00:15 GMT (envelope-from gnats) Date: Tue, 6 Jan 2009 19:00:15 GMT Message-Id: <200901061900.n06J0Fcl073538@freefall.freebsd.org> To: freebsd-standards@FreeBSD.org From: David Schultz 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: David Schultz List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2009 19:00:15 -0000 The following reply was made to PR standards/130067; it has been noted by GNATS. From: David Schultz To: Bruce Evans Cc: Vaclav Haisman , imp@FreeBSD.ORG, freebsd-gnats-submit@FreeBSD.ORG, freebsd-standards@FreeBSD.ORG Subject: Re: standards/130067: Wrong numeric limits in system headers? Date: Tue, 6 Jan 2009 14:03:13 -0500 On FreeBSD/i386, long doubles are represented with 64 bits of precision, but computations are performed with 53 bits of precision. In a sane world, this discrepancy wouldn't exist, but for reasons I won't get into, they do, and probably always will. C99 defines the LDBL constants based on what can be represented, not what can be computed as the result of arithmetic operations, so my interpretation is that the values in float.h are correct, though confusing. From owner-freebsd-standards@FreeBSD.ORG Tue Jan 6 19:23:03 2009 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 1E922106564A; Tue, 6 Jan 2009 19:23:03 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id CFF768FC12; Tue, 6 Jan 2009 19:23:02 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.3/8.14.2) with ESMTP id n06J3EjU015283; Tue, 6 Jan 2009 14:03:14 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.3/8.14.2/Submit) id n06J3DXq015282; Tue, 6 Jan 2009 14:03:13 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Tue, 6 Jan 2009 14:03:13 -0500 From: David Schultz To: Bruce Evans Message-ID: <20090106190313.GA15233@zim.MIT.EDU> Mail-Followup-To: Bruce Evans , Vaclav Haisman , imp@FreeBSD.ORG, freebsd-gnats-submit@FreeBSD.ORG, freebsd-standards@FreeBSD.ORG References: <200812302231.mBUMVUtf092910@www.freebsd.org> <20081231215445.S3923@delplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081231215445.S3923@delplex.bde.org> Cc: freebsd-standards@FreeBSD.ORG, Vaclav Haisman , imp@FreeBSD.ORG, freebsd-gnats-submit@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: Tue, 06 Jan 2009 19:23:03 -0000 On FreeBSD/i386, long doubles are represented with 64 bits of precision, but computations are performed with 53 bits of precision. In a sane world, this discrepancy wouldn't exist, but for reasons I won't get into, they do, and probably always will. C99 defines the LDBL constants based on what can be represented, not what can be computed as the result of arithmetic operations, so my interpretation is that the values in float.h are correct, though confusing. From owner-freebsd-standards@FreeBSD.ORG Thu Jan 8 21:57:12 2009 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 164AF106566B; Thu, 8 Jan 2009 21:57:12 +0000 (UTC) (envelope-from v.haisman@sh.cvut.cz) Received: from service1.sh.cvut.cz (service1.sh.cvut.cz [IPv6:2001:718:2::214]) by mx1.freebsd.org (Postfix) with ESMTP id 6ACE58FC0A; Thu, 8 Jan 2009 21:57:11 +0000 (UTC) (envelope-from v.haisman@sh.cvut.cz) Received: from localhost (localhost [127.0.0.1]) by service1.sh.cvut.cz (Postfix) with ESMTP id 960DA124086; Thu, 8 Jan 2009 22:57:09 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at service1.sh.cvut.cz X-Spam-Score: -87.588 X-Spam-Level: X-Spam-Status: No, score=-87.588 tagged_above=-255 required=5 tests=[ALL_TRUSTED=-1.44, AWL=14.852, CRM114_HAM_00=, SMTPAUTH_SHDOMAIN=-100] Received: from service1.sh.cvut.cz ([127.0.0.1]) by localhost (service1.sh.cvut.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQNiertStr-G; Thu, 8 Jan 2009 22:57:01 +0100 (CET) Received: from [192.168.1.2] (35.201.broadband4.iol.cz [85.71.201.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: v.haisman@sh.cvut.cz) by service1.sh.cvut.cz (Postfix) with ESMTP id B12B4124085; Thu, 8 Jan 2009 22:57:01 +0100 (CET) Message-ID: <496676AB.9040905@sh.cvut.cz> Date: Thu, 08 Jan 2009 22:56:59 +0100 From: =?UTF-8?B?VsOhY2xhdiBIYWlzbWFu?= User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Bruce Evans , Vaclav Haisman , imp@FreeBSD.ORG, freebsd-gnats-submit@FreeBSD.ORG, freebsd-standards@FreeBSD.ORG References: <200812302231.mBUMVUtf092910@www.freebsd.org> <20081231215445.S3923@delplex.bde.org> <20090106190313.GA15233@zim.MIT.EDU> In-Reply-To: <20090106190313.GA15233@zim.MIT.EDU> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 21:57:12 -0000 David Schultz wrote, On 6.1.2009 20:03: > On FreeBSD/i386, long doubles are represented with 64 bits of > precision, but computations are performed with 53 bits of > precision. In a sane world, this discrepancy wouldn't exist, but > for reasons I won't get into, they do, and probably always will. > > C99 defines the LDBL constants based on what can be represented, > not what can be computed as the result of arithmetic operations, > so my interpretation is that the values in float.h are correct, > though confusing. I am not language lawyer but even if it were true that the constants are right, there is still the problem that they (especially the LDBL_MAX value) are useless with the provided GCC. Either GCC or the headers should be changed. Otherwise the constants are rather useless and unusable. -- VH From owner-freebsd-standards@FreeBSD.ORG Thu Jan 8 22:00:11 2009 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 4DAAE1065674 for ; Thu, 8 Jan 2009 22:00:11 +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 081E78FC1C for ; Thu, 8 Jan 2009 22:00:11 +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 n08M0AUb090351 for ; Thu, 8 Jan 2009 22:00:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n08M0Ams090350; Thu, 8 Jan 2009 22:00:10 GMT (envelope-from gnats) Date: Thu, 8 Jan 2009 22:00:10 GMT Message-Id: <200901082200.n08M0Ams090350@freefall.freebsd.org> To: freebsd-standards@FreeBSD.org From: =?UTF-8?B?VsOhY2xhdiBIYWlzbWFu?= 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: =?UTF-8?B?VsOhY2xhdiBIYWlzbWFu?= List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 22:00:11 -0000 The following reply was made to PR standards/130067; it has been noted by GNATS. From: =?UTF-8?B?VsOhY2xhdiBIYWlzbWFu?= To: Bruce Evans , Vaclav Haisman , imp@FreeBSD.ORG, freebsd-gnats-submit@FreeBSD.ORG, freebsd-standards@FreeBSD.ORG Cc: Subject: Re: standards/130067: Wrong numeric limits in system headers? Date: Thu, 08 Jan 2009 22:56:59 +0100 David Schultz wrote, On 6.1.2009 20:03: > On FreeBSD/i386, long doubles are represented with 64 bits of > precision, but computations are performed with 53 bits of > precision. In a sane world, this discrepancy wouldn't exist, but > for reasons I won't get into, they do, and probably always will. > > C99 defines the LDBL constants based on what can be represented, > not what can be computed as the result of arithmetic operations, > so my interpretation is that the values in float.h are correct, > though confusing. I am not language lawyer but even if it were true that the constants are right, there is still the problem that they (especially the LDBL_MAX value) are useless with the provided GCC. Either GCC or the headers should be changed. Otherwise the constants are rather useless and unusable. -- VH From owner-freebsd-standards@FreeBSD.ORG Fri Jan 9 16:00:09 2009 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 DF6F1106566B for ; Fri, 9 Jan 2009 16:00:09 +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 C961E8FC13 for ; Fri, 9 Jan 2009 16:00:09 +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 n09G09wx028177 for ; Fri, 9 Jan 2009 16:00:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n09G091i028176; Fri, 9 Jan 2009 16:00:09 GMT (envelope-from gnats) Date: Fri, 9 Jan 2009 16:00:09 GMT Message-Id: <200901091600.n09G091i028176@freefall.freebsd.org> To: freebsd-standards@FreeBSD.org From: John Hein 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: John Hein List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 16:00:10 -0000 The following reply was made to PR standards/130067; it has been noted by GNATS. From: John Hein To: =?UTF-8?B?VsOhY2xhdiBIYWlzbWFu?= Cc: Bruce Evans , das@FreeBSD.ORG, imp@FreeBSD.ORG, freebsd-gnats-submit@FreeBSD.ORG, freebsd-standards@FreeBSD.ORG Subject: Re: standards/130067: Wrong numeric limits in system headers? Date: Fri, 9 Jan 2009 08:57:26 -0700 V=E1clav Haisman wrote at 22:56 +0100 on Jan 8, 2009: > David Schultz wrote, On 6.1.2009 20:03: > > On FreeBSD/i386, long doubles are represented with 64 bits of > > precision, but computations are performed with 53 bits of > > precision. In a sane world, this discrepancy wouldn't exist, but > > for reasons I won't get into, they do, and probably always will. > > = > > C99 defines the LDBL constants based on what can be represented, > > not what can be computed as the result of arithmetic operations, > > so my interpretation is that the values in float.h are correct, > > though confusing. > I am not language lawyer but even if it were true that the constants a= re > right, there is still the problem that they (especially the LDBL_MAX v= alue) > are useless with the provided GCC. Either GCC or the headers should be= > changed. Otherwise the constants are rather useless and unusable. FWIW, when you compile the OP's sample code on i386 with -pedantic (with 6.x's base gcc 3.4.6 or 7.x's base gcc 4.2.1), you get: x.cc:11: error: floating constant exceeds range of 'long double' (the LDBL_MAX line) That seems to tip the scale more to the 'float.h is wrong' side. From owner-freebsd-standards@FreeBSD.ORG Fri Jan 9 17:07:46 2009 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 D7A961065673; Fri, 9 Jan 2009 17:07:46 +0000 (UTC) (envelope-from jhein@timing.com) Received: from Daffy.timing.com (mx2.timing.com [206.168.13.218]) by mx1.freebsd.org (Postfix) with ESMTP id 9BA658FC19; Fri, 9 Jan 2009 17:07:46 +0000 (UTC) (envelope-from jhein@timing.com) Received: from gromit.timing.com (gromit.timing.com [206.168.13.209]) by Daffy.timing.com (8.13.1/8.13.1) with ESMTP id n09GZlO6096184; Fri, 9 Jan 2009 09:35:48 -0700 (MST) (envelope-from jhein@timing.com) Received: from gromit.timing.com (localhost [127.0.0.1]) by gromit.timing.com (8.14.3/8.14.3) with ESMTP id n09FvWJF086273; Fri, 9 Jan 2009 08:57:32 -0700 (MST) (envelope-from jhein@gromit.timing.com) Received: (from jhein@localhost) by gromit.timing.com (8.14.3/8.14.3/Submit) id n09FvQCB086267; Fri, 9 Jan 2009 08:57:26 -0700 (MST) (envelope-from jhein) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <18791.29670.321788.799095@gromit.timing.com> Date: Fri, 9 Jan 2009 08:57:26 -0700 From: John Hein To: =?UTF-8?B?VsOhY2xhdiBIYWlzbWFu?= In-Reply-To: <496676AB.9040905@sh.cvut.cz> References: <200812302231.mBUMVUtf092910@www.freebsd.org> <20081231215445.S3923@delplex.bde.org> <20090106190313.GA15233@zim.MIT.EDU> <496676AB.9040905@sh.cvut.cz> X-Mailer: VM 7.19 under Emacs 22.3.1 X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on Daffy.timing.com X-Virus-Status: Clean Cc: freebsd-standards@FreeBSD.ORG, das@FreeBSD.ORG, freebsd-gnats-submit@FreeBSD.ORG, imp@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: Fri, 09 Jan 2009 17:07:47 -0000 V=E1clav Haisman wrote at 22:56 +0100 on Jan 8, 2009: > David Schultz wrote, On 6.1.2009 20:03: > > On FreeBSD/i386, long doubles are represented with 64 bits of > > precision, but computations are performed with 53 bits of > > precision. In a sane world, this discrepancy wouldn't exist, but > > for reasons I won't get into, they do, and probably always will. > > = > > C99 defines the LDBL constants based on what can be represented, > > not what can be computed as the result of arithmetic operations, > > so my interpretation is that the values in float.h are correct, > > though confusing. > I am not language lawyer but even if it were true that the constants a= re > right, there is still the problem that they (especially the LDBL_MAX v= alue) > are useless with the provided GCC. Either GCC or the headers should be= > changed. Otherwise the constants are rather useless and unusable. FWIW, when you compile the OP's sample code on i386 with -pedantic (with 6.x's base gcc 3.4.6 or 7.x's base gcc 4.2.1), you get: x.cc:11: error: floating constant exceeds range of 'long double' (the LDBL_MAX line) That seems to tip the scale more to the 'float.h is wrong' side. From owner-freebsd-standards@FreeBSD.ORG Fri Jan 9 18:41:17 2009 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 621CB1065674; Fri, 9 Jan 2009 18:41:17 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 1BB728FC0C; Fri, 9 Jan 2009 18:41:16 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.3/8.14.2) with ESMTP id n09IfbPa061269; Fri, 9 Jan 2009 13:41:37 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.3/8.14.2/Submit) id n09Ifaj3061268; Fri, 9 Jan 2009 13:41:36 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Fri, 9 Jan 2009 13:41:36 -0500 From: David Schultz To: John Hein Message-ID: <20090109184136.GA61165@zim.MIT.EDU> Mail-Followup-To: John Hein , =?iso-8859-1?Q?V=E1clav?= Haisman , freebsd-standards@FreeBSD.ORG, freebsd-gnats-submit@FreeBSD.ORG, imp@FreeBSD.ORG References: <200812302231.mBUMVUtf092910@www.freebsd.org> <20081231215445.S3923@delplex.bde.org> <20090106190313.GA15233@zim.MIT.EDU> <496676AB.9040905@sh.cvut.cz> <18791.29670.321788.799095@gromit.timing.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18791.29670.321788.799095@gromit.timing.com> Cc: imp@FreeBSD.ORG, =?iso-8859-1?Q?V=E1clav?= Haisman , freebsd-standards@FreeBSD.ORG, freebsd-gnats-submit@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: Fri, 09 Jan 2009 18:41:17 -0000 On Fri, Jan 09, 2009, John Hein wrote: > FWIW, when you compile the OP's sample code on i386 with -pedantic > (with 6.x's base gcc 3.4.6 or 7.x's base gcc 4.2.1), you get: > > x.cc:11: error: floating constant exceeds range of 'long double' > > (the LDBL_MAX line) > > That seems to tip the scale more to the 'float.h is wrong' side. gcc doesn't do quite the right thing with long double constants in FreeBSD, and it causes no end of trouble when writing long double routines that are intended to work when the FPU is switched to extended precision mode. Older versions of gcc would evaluate long double constant expressions at compile time using extended precision, which was wrong because it didn't reflect what the FPU would have done at runtime. More recent versions of gcc were "fixed" to evaluate all long double constants using double precision, which matches what the FPU does by default. However, now it's not even possible to write a program that uses long double constants, even if the program changes the FPU precision at runtime, because gcc truncates all the constants at compile time (and generates spurious complaints such as the one you mention). C99 defines some pragmas that would improve the situation, but gcc doesn't implement them. From owner-freebsd-standards@FreeBSD.ORG Fri Jan 9 18:50:03 2009 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 6074210656CD for ; Fri, 9 Jan 2009 18:50: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 3AE338FC26 for ; Fri, 9 Jan 2009 18:50: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 n09Io32a056250 for ; Fri, 9 Jan 2009 18:50:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n09Io349056249; Fri, 9 Jan 2009 18:50:03 GMT (envelope-from gnats) Date: Fri, 9 Jan 2009 18:50:03 GMT Message-Id: <200901091850.n09Io349056249@freefall.freebsd.org> To: freebsd-standards@FreeBSD.org From: David Schultz 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: David Schultz List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 18:50:04 -0000 The following reply was made to PR standards/130067; it has been noted by GNATS. From: David Schultz To: John Hein Cc: =?iso-8859-1?Q?V=E1clav?= Haisman , freebsd-standards@FreeBSD.ORG, freebsd-gnats-submit@FreeBSD.ORG, imp@FreeBSD.ORG Subject: Re: standards/130067: Wrong numeric limits in system headers? Date: Fri, 9 Jan 2009 13:41:36 -0500 On Fri, Jan 09, 2009, John Hein wrote: > FWIW, when you compile the OP's sample code on i386 with -pedantic > (with 6.x's base gcc 3.4.6 or 7.x's base gcc 4.2.1), you get: > > x.cc:11: error: floating constant exceeds range of 'long double' > > (the LDBL_MAX line) > > That seems to tip the scale more to the 'float.h is wrong' side. gcc doesn't do quite the right thing with long double constants in FreeBSD, and it causes no end of trouble when writing long double routines that are intended to work when the FPU is switched to extended precision mode. Older versions of gcc would evaluate long double constant expressions at compile time using extended precision, which was wrong because it didn't reflect what the FPU would have done at runtime. More recent versions of gcc were "fixed" to evaluate all long double constants using double precision, which matches what the FPU does by default. However, now it's not even possible to write a program that uses long double constants, even if the program changes the FPU precision at runtime, because gcc truncates all the constants at compile time (and generates spurious complaints such as the one you mention). C99 defines some pragmas that would improve the situation, but gcc doesn't implement them. From owner-freebsd-standards@FreeBSD.ORG Sat Jan 10 11:36:14 2009 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 1D4AB1065676; Sat, 10 Jan 2009 11:36:14 +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 mx1.freebsd.org (Postfix) with ESMTP id A8B568FC14; Sat, 10 Jan 2009 11:36:13 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c122-106-161-228.carlnfd1.nsw.optusnet.com.au (c122-106-161-228.carlnfd1.nsw.optusnet.com.au [122.106.161.228]) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n0ABZxWB027918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 Jan 2009 22:36:09 +1100 Date: Sat, 10 Jan 2009 22:35:59 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: David Schultz In-Reply-To: <20090109184136.GA61165@zim.MIT.EDU> Message-ID: <20090110215409.P28834@delplex.bde.org> References: <200812302231.mBUMVUtf092910@www.freebsd.org> <20081231215445.S3923@delplex.bde.org> <20090106190313.GA15233@zim.MIT.EDU> <496676AB.9040905@sh.cvut.cz> <18791.29670.321788.799095@gromit.timing.com> <20090109184136.GA61165@zim.MIT.EDU> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-standards@freebsd.org, freebsd-gnats-submit@freebsd.org, =?iso-8859-1?Q?V=E1clav?= Haisman , imp@freebsd.org, John Hein 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: Sat, 10 Jan 2009 11:36:14 -0000 On Fri, 9 Jan 2009, David Schultz wrote: > On Fri, Jan 09, 2009, John Hein wrote: >> FWIW, when you compile the OP's sample code on i386 with -pedantic >> (with 6.x's base gcc 3.4.6 or 7.x's base gcc 4.2.1), you get: >> >> x.cc:11: error: floating constant exceeds range of 'long double' >> >> (the LDBL_MAX line) >> >> That seems to tip the scale more to the 'float.h is wrong' side. No, it is strictly a bug in gcc (gcc is supposed to support FreeBSD's idea of a long double, since the special support is only used by FreeBSD, but it doesn't). The FreeBSD value of LDBL_MAX doesn't exceed the range of a long double with FreeBSD's idea of a long double. However, almost any operation on FreeBSD's LDBL_MAX would overflow. E.g., (LDBL_MAX + 0) and (LDBL_MAX * 1) both overflow to give a result of Inf. There may be optimization bugs related to this -- IIRC, evaluating x+0 as x at compile time is an invalid optimization, because x+0 should differ from x iff x is -0, but evaluating x*1 as x at compile time is a valid optimization because there should be no special cases; however LDBL_MAX*1 gives a special case. > gcc doesn't do quite the right thing with long double constants in > FreeBSD, and it causes no end of trouble when writing long double > routines that are intended to work when the FPU is switched to > extended precision mode. I think it does do the right thing from its viewpoint. In its viewpoint, long doubles have only 53 bits of precision. Since it refuses to construct long doubles with the full 64 bits of precision that are possible and expected by FreeBSD, this is a valid viewpoint -- there is no way to construct a long double with more than 53 bits of precision in C without invoking undefined behaviour, so the extra bits might as well not be there. This viewpoint also avoids surprises like LDBL_MAX*1 = Inf. > Older versions of gcc would evaluate long double constant > expressions at compile time using extended precision, which was > wrong because it didn't reflect what the FPU would have done at > runtime. More recent versions of gcc were "fixed" to evaluate all > long double constants using double precision, which matches what > the FPU does by default. However, now it's not even possible to > write a program that uses long double constants, even if the > program changes the FPU precision at runtime, because gcc > truncates all the constants at compile time (and generates > spurious complaints such as the one you mention). C99 defines some > pragmas that would improve the situation, but gcc doesn't > implement them. This is true. Bruce From owner-freebsd-standards@FreeBSD.ORG Sat Jan 10 11:40:03 2009 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 4BA881065672 for ; Sat, 10 Jan 2009 11:40: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 39CA78FC14 for ; Sat, 10 Jan 2009 11:40: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 n0ABe2Zp058114 for ; Sat, 10 Jan 2009 11:40:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n0ABe2oD058113; Sat, 10 Jan 2009 11:40:02 GMT (envelope-from gnats) Date: Sat, 10 Jan 2009 11:40:02 GMT Message-Id: <200901101140.n0ABe2oD058113@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: Sat, 10 Jan 2009 11:40:03 -0000 The following reply was made to PR standards/130067; it has been noted by GNATS. From: Bruce Evans To: David Schultz Cc: John Hein , imp@freebsd.org, =?iso-8859-1?Q?V=E1clav?= Haisman , freebsd-standards@freebsd.org, freebsd-gnats-submit@freebsd.org Subject: Re: standards/130067: Wrong numeric limits in system headers? Date: Sat, 10 Jan 2009 22:35:59 +1100 (EST) On Fri, 9 Jan 2009, David Schultz wrote: > On Fri, Jan 09, 2009, John Hein wrote: >> FWIW, when you compile the OP's sample code on i386 with -pedantic >> (with 6.x's base gcc 3.4.6 or 7.x's base gcc 4.2.1), you get: >> >> x.cc:11: error: floating constant exceeds range of 'long double' >> >> (the LDBL_MAX line) >> >> That seems to tip the scale more to the 'float.h is wrong' side. No, it is strictly a bug in gcc (gcc is supposed to support FreeBSD's idea of a long double, since the special support is only used by FreeBSD, but it doesn't). The FreeBSD value of LDBL_MAX doesn't exceed the range of a long double with FreeBSD's idea of a long double. However, almost any operation on FreeBSD's LDBL_MAX would overflow. E.g., (LDBL_MAX + 0) and (LDBL_MAX * 1) both overflow to give a result of Inf. There may be optimization bugs related to this -- IIRC, evaluating x+0 as x at compile time is an invalid optimization, because x+0 should differ from x iff x is -0, but evaluating x*1 as x at compile time is a valid optimization because there should be no special cases; however LDBL_MAX*1 gives a special case. > gcc doesn't do quite the right thing with long double constants in > FreeBSD, and it causes no end of trouble when writing long double > routines that are intended to work when the FPU is switched to > extended precision mode. I think it does do the right thing from its viewpoint. In its viewpoint, long doubles have only 53 bits of precision. Since it refuses to construct long doubles with the full 64 bits of precision that are possible and expected by FreeBSD, this is a valid viewpoint -- there is no way to construct a long double with more than 53 bits of precision in C without invoking undefined behaviour, so the extra bits might as well not be there. This viewpoint also avoids surprises like LDBL_MAX*1 = Inf. > Older versions of gcc would evaluate long double constant > expressions at compile time using extended precision, which was > wrong because it didn't reflect what the FPU would have done at > runtime. More recent versions of gcc were "fixed" to evaluate all > long double constants using double precision, which matches what > the FPU does by default. However, now it's not even possible to > write a program that uses long double constants, even if the > program changes the FPU precision at runtime, because gcc > truncates all the constants at compile time (and generates > spurious complaints such as the one you mention). C99 defines some > pragmas that would improve the situation, but gcc doesn't > implement them. This is true. Bruce