From owner-freebsd-standards@FreeBSD.ORG Sun Feb 20 14:16:54 2011 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 DCB9A106566B for ; Sun, 20 Feb 2011 14:16:54 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 7B3F88FC1B for ; Sun, 20 Feb 2011 14:16:54 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id 59E4835934F; Sun, 20 Feb 2011 15:16:53 +0100 (CET) Received: by turtle.stack.nl (Postfix, from userid 1677) id 447A5170FB; Sun, 20 Feb 2011 15:16:53 +0100 (CET) Date: Sun, 20 Feb 2011 15:16:53 +0100 From: Jilles Tjoelker To: d@delphij.net Message-ID: <20110220141653.GB95092@stack.nl> References: <4D53064B.7090901@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D53064B.7090901@delphij.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-standards@freebsd.org Subject: Re: Should we imitate GNU test's insanity? 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: Sun, 20 Feb 2011 14:16:54 -0000 On Wed, Feb 09, 2011 at 01:25:31PM -0800, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > On 02/09/11 12:46, Chris Rees wrote: > > I've found so many cases of autoconf failing when porting Linux apps > > over, for example scilab and musicpd due to the happiness of GNU test > > to accept a == b rather than a = b. > > Rather than making a bug report that'll be brushed off (as my bug > > report for GNU find was), would it be unthinkable for me to make a > > patch for our test to make == acceptable, to stop some wasted porters' > > time? > I don't think == is unacceptable extension to the POSIX standard based > on my reading. If there is no objection I'll commit the attached patch > on Friday. > Index: bin/test/test.c > =================================================================== > --- bin/test/test.c (revision 218497) > +++ bin/test/test.c (working copy) > @@ -140,6 +140,7 @@ > {"-L", FILSYM, UNOP}, > {"-S", FILSOCK,UNOP}, > {"=", STREQ, BINOP}, > + {"==", STREQ, BINOP}, > {"!=", STRNE, BINOP}, > {"<", STRLT, BINOP}, > {">", STRGT, BINOP}, Although I agree that this may be left undocumented, I think you should add a test to tools/regression/bin/test/regress.sh, given that you care enough to make this change. That I do not object to this change does not mean that this fairly useless (apart from compatibility) feature should be added to POSIX. -- Jilles Tjoelker From owner-freebsd-standards@FreeBSD.ORG Mon Feb 21 11:07:09 2011 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 17FAB1065679 for ; Mon, 21 Feb 2011 11:07:09 +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 F07B18FC12 for ; Mon, 21 Feb 2011 11:07:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p1LB78HA075836 for ; Mon, 21 Feb 2011 11:07:08 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p1LB78dR075834 for freebsd-standards@FreeBSD.org; Mon, 21 Feb 2011 11:07:08 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 21 Feb 2011 11:07:08 GMT Message-Id: <201102211107.p1LB78dR075834@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, 21 Feb 2011 11:07:09 -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/154873 standards ZFS violates POSIX on open/O_CREAT -> ftruncate o stand/154842 standards invalid request authenticator in the second and subseq o stand/153756 standards fp leak in hesiod.c . o stand/152415 standards [libm] implementation of expl() o stand/150093 standards C++ std::locale support is broken a stand/149980 standards [libc] [patch] negative value integer to nanosleep(2) o stand/147210 standards xmmintrin.h and cstdlib conflicts with each other with o docs/143472 standards gethostname(3) references undefined value: HOST_NAME_M o stand/142803 standards j0 Bessel function inaccurate near zeros of the functi s stand/141705 standards [libc] [request] libc lacks cexp (and friends) o stand/130067 standards Wrong numeric limits in system headers? 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/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 stand/114633 standards /etc/rc.subr: line 511: omits a quotation mark: "force 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/94729 standards [libc] fcntl() throws undocumented ENOTTY a stand/86484 standards [patch] mkfifo(1) uses wrong permissions 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/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( o stand/56476 standards [patch] cd9660 unicode support simple hack 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/44365 standards [headers] [patch] [request] introduce ulong and unchar a stand/41576 standards ln(1): replacing old dir-symlinks o stand/39256 standards snprintf/vsnprintf aren't POSIX-conformant for strings a docs/26003 standards getgroups(2) lists NGROUPS_MAX but not syslimits.h s stand/24590 standards timezone function not compatible witn Single Unix Spec o stand/21519 standards sys/dir.h should be deprecated some more s bin/14925 standards getsubopt isn't poisonous enough 42 problems total. From owner-freebsd-standards@FreeBSD.ORG Tue Feb 22 21:42:01 2011 Return-Path: Delivered-To: standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04F44106564A; Tue, 22 Feb 2011 21:42:01 +0000 (UTC) (envelope-from brucec@freebsd.org) Received: from muon.cran.org.uk (unknown [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 906088FC14; Tue, 22 Feb 2011 21:42:00 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id C65A6E8BA7; Tue, 22 Feb 2011 21:41:57 +0000 (GMT) Received: from core.nessbank (client-86-31-236-253.oxfd.adsl.virginmedia.com [86.31.236.253]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id A86DDE8838; Tue, 22 Feb 2011 21:41:57 +0000 (GMT) From: Bruce Cran To: bug-followup@freebsd.org, dan@obluda.cz, standards@freebsd.org Date: Tue, 22 Feb 2011 21:41:54 +0000 User-Agent: KMail/1.13.5 (FreeBSD/9.0-CURRENT; KDE/4.5.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_i2CZNPTu+b2EAx0" Message-Id: <201102222141.54428.brucec@freebsd.org> Cc: Subject: Re: docs/125751: man 3 pthread_getschedparam section ERRORS incomplete 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, 22 Feb 2011 21:42:01 -0000 --Boundary-00=_i2CZNPTu+b2EAx0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit According to POSIX EINVAL isn't a valid return value, which is why it's not documented. It appears that if the parameters are NULL 0 is expected to be returned; in glibc on Linux if both are NULL then 0 is returned otherwise if just one is NULL then a segfault occurs. I'd like to commit the attached patch which I think brings the implementation more in-line with POSIX: return 0 if either parameters are NULL and return ESRCH from functions which search for a pthread_t if a thread doesn't exist regardless of whether it's NULL or otherwise. -- Bruce Cran --Boundary-00=_i2CZNPTu+b2EAx0 Content-Type: text/x-patch; charset="ISO-8859-1"; name="pthread.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="pthread.diff" Index: thr_list.c =================================================================== --- thr_list.c (revision 218951) +++ thr_list.c (working copy) @@ -283,7 +283,7 @@ if (thread == NULL) /* Invalid thread: */ - return (EINVAL); + return (ESRCH); if ((ret = _thr_find_thread(curthread, thread, include_dead)) == 0) { thread->refcount++; @@ -334,7 +334,7 @@ int ret; if (thread == NULL) - return (EINVAL); + return (ESRCH); ret = 0; THREAD_LIST_RDLOCK(curthread); Index: thr_getschedparam.c =================================================================== --- thr_getschedparam.c (revision 218951) +++ thr_getschedparam.c (working copy) @@ -51,7 +51,7 @@ int ret; if (policy == NULL || param == NULL) - return (EINVAL); + return (0); if (pthread == curthread) { /* --Boundary-00=_i2CZNPTu+b2EAx0-- From owner-freebsd-standards@FreeBSD.ORG Tue Feb 22 21:54:14 2011 Return-Path: Delivered-To: standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0E801065695; Tue, 22 Feb 2011 21:54:14 +0000 (UTC) (envelope-from dan@obluda.cz) Received: from smtp1.kolej.mff.cuni.cz (smtp1.kolej.mff.cuni.cz [IPv6:2001:718:1e03:a01::a]) by mx1.freebsd.org (Postfix) with ESMTP id 665D08FC0A; Tue, 22 Feb 2011 21:54:14 +0000 (UTC) X-Envelope-From: dan@obluda.cz Received: from kgw.obluda.cz (kgw.obluda.cz [193.179.199.50]) by smtp1.kolej.mff.cuni.cz (8.14.4/8.14.4) with ESMTP id p1MLsCKk047598; Tue, 22 Feb 2011 22:54:13 +0100 (CET) (envelope-from dan@obluda.cz) Message-ID: <4D643083.8040606@obluda.cz> Date: Tue, 22 Feb 2011 22:54:11 +0100 From: Dan Lukes User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.16) Gecko/20101218 SeaMonkey/2.0.11 MIME-Version: 1.0 To: Bruce Cran References: <201102222141.54428.brucec@freebsd.org> In-Reply-To: <201102222141.54428.brucec@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: standards@freebsd.org, bug-followup@freebsd.org Subject: Re: docs/125751: man 3 pthread_getschedparam section ERRORS incomplete 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, 22 Feb 2011 21:54:14 -0000 On 02/22/11 22:41, Bruce Cran: > According to POSIX EINVAL isn't a valid return value I don't have problem with proposed patch. I reported the issue because I got EIVAL and it has not been documented. Either code or documentation needs to be changed to make them consistent, but I don't care what part will be corrected. Thank you for taking those ancient PRs ... Dan From owner-freebsd-standards@FreeBSD.ORG Wed Feb 23 21:40:08 2011 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 A11E8106564A for ; Wed, 23 Feb 2011 21:40:08 +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 74BE88FC16 for ; Wed, 23 Feb 2011 21:40:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p1NLe8Jb010842 for ; Wed, 23 Feb 2011 21:40:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p1NLe84o010841; Wed, 23 Feb 2011 21:40:08 GMT (envelope-from gnats) Date: Wed, 23 Feb 2011 21:40:08 GMT Message-Id: <201102232140.p1NLe84o010841@freefall.freebsd.org> To: freebsd-standards@FreeBSD.org From: Alexander Best Cc: Subject: Re: standards/149980: [libc] [patch] negative value integer to nanosleep(2) should fail with EINVAL X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alexander Best List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 21:40:08 -0000 The following reply was made to PR standards/149980; it has been noted by GNATS. From: Alexander Best To: bug-followup@freebsd.org Cc: Subject: Re: standards/149980: [libc] [patch] negative value integer to nanosleep(2) should fail with EINVAL Date: Wed, 23 Feb 2011 21:38:02 +0000 since this might break some ports or 3rd party applications, how about adding something like kern.allow_negative_sleep? cheers. alex -- a13x From owner-freebsd-standards@FreeBSD.ORG Wed Feb 23 23:07:13 2011 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 39086106566C; Wed, 23 Feb 2011 23:07:13 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.freebsd.org (Postfix) with ESMTP id CAEA38FC1A; Wed, 23 Feb 2011 23:07:12 +0000 (UTC) Received: from c122-107-114-89.carlnfd1.nsw.optusnet.com.au (c122-107-114-89.carlnfd1.nsw.optusnet.com.au [122.107.114.89]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p1NN78fr001006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Feb 2011 10:07:10 +1100 Date: Thu, 24 Feb 2011 10:07:08 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Alexander Best In-Reply-To: <201102232140.p1NLe84o010841@freefall.freebsd.org> Message-ID: <20110224091827.K1658@besplex.bde.org> References: <201102232140.p1NLe84o010841@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-standards@freebsd.org Subject: Re: standards/149980: [libc] [patch] negative value integer to nanosleep(2) should fail with EINVAL 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, 23 Feb 2011 23:07:13 -0000 On Wed, 23 Feb 2011, Alexander Best wrote: > The following reply was made to PR standards/149980; it has been noted by GNATS. > > From: Alexander Best > To: bug-followup@freebsd.org > Cc: > Subject: Re: standards/149980: [libc] [patch] negative value integer to nanosleep(2) should fail with EINVAL > Date: Wed, 23 Feb 2011 21:38:02 +0000 > > since this might break some ports or 3rd party applications, how about adding > something like kern.allow_negative_sleep? It shouldn't fail. POSIX doesn't require it to fail, at least in the old 2001 draft7: % 26886 ERRORS % 26887 The nanosleep( ) function shall fail if: % 26888 [EINTR] The nanosleep( ) function was interrupted by a signal. % 26889 [EINVAL] The rqtp argument specified a nanosecond value less than zero or greater than % 26890 or equal to 1000 million. It just specifies EINVAL for out-of-bounds nanoseconds values because those give an invalid timeval. Negative values for the seconds field are valid if they are representable. A negative sleep time is equally physically impossible as a sleep time of 0, but I haven't seen any proposals to break the latter. But if you want full breakage, be sure to disallow both negative timevals and ones longer than the lifetime of the universe ;-). In private or maybe public old mail about this, I pointed out bugs in itimerfix() and itimespecfix(). These functions do generate EINVAL for negative times and are very broken for large positive values considerably shorter than the lifetime of the universe for 32-bit time_t's but considerably longer than the lifetime of the universe for 64-bit time_t's. Callers depend on the time_t's being considerably less than the time until the time_t's wrap around. This used ti be avoided (until 2035 for 32-bit signed time_t's) by restricting the time_t's to 1000 million seconds (3+ years) in itimerfix(). This has been broken, so anyone who can make syscalls that use itimers can cause overflows in the kernel. Limiting the maximum itimer to 100 million seconds or even the lifetime of the univers is not supported by POSIX, but it is what BSD always did until FreeBSD broke it. itimerfix() and itimespecfix() also do bogus rounding up to a multiple of the timer granularity. This is mostly cosmetic, but breaks syscalls that return residual times. itimespecfix() also has a namespace error. It corresponds to itimerfix(). There is no itimevalfix(), but there is a confusingly similar timevalfix(). These bugs don't directly affect nanosleep(), since it doesn't use itimespecfix(), perhaps intentionally to avoid breaking it for negative times. Its overflow bugs bugs are smaller in nanosleep(), since it loops internally to handle large times and its algorithm of comparing the current time with the end time in case it wakes up early is fairly robust. However, it blindly adds timespecs using timespecadd(&ts, rqt), where ts is initially the current time (spec) and *rqt is the arg, and ts is finally the end time. *rqt must be limited to prevent overflow of this. The usual (but broken) limit of 100 million seconds would work (until 2035) as elsewhere. When overflow occurs, the result is undefined. The actual behaviour is normally a garbage negative end time in ts, and although there are lots of compensating overflows (adding and subtracting the current time), I think the logic isn't all accidentally correct throughout. Bruce From owner-freebsd-standards@FreeBSD.ORG Wed Feb 23 23:27:06 2011 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 2E8131065674; Wed, 23 Feb 2011 23:27:06 +0000 (UTC) Date: Wed, 23 Feb 2011 23:27:06 +0000 From: Alexander Best To: Bruce Evans Message-ID: <20110223232706.GA43593@freebsd.org> References: <201102232140.p1NLe84o010841@freefall.freebsd.org> <20110224091827.K1658@besplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110224091827.K1658@besplex.bde.org> Cc: freebsd-standards@freebsd.org Subject: Re: standards/149980: [libc] [patch] negative value integer to nanosleep(2) should fail with EINVAL 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, 23 Feb 2011 23:27:06 -0000 On Thu Feb 24 11, Bruce Evans wrote: > On Wed, 23 Feb 2011, Alexander Best wrote: > > >The following reply was made to PR standards/149980; it has been noted by > >GNATS. > > > >From: Alexander Best > >To: bug-followup@freebsd.org > >Cc: > >Subject: Re: standards/149980: [libc] [patch] negative value integer to > >nanosleep(2) should fail with EINVAL > >Date: Wed, 23 Feb 2011 21:38:02 +0000 > > > >since this might break some ports or 3rd party applications, how about > >adding > >something like kern.allow_negative_sleep? > > It shouldn't fail. POSIX doesn't require it to fail, at least in the old > 2001 draft7: yes. the same entry is in IEEE Std 1003.1-2008. however Garrett Cooper mentioned in his PR that he talked to some POSIX people and so his information might be different from the one in the specs. it might be possible that the POSIX people expect time_t to be unsigned. i think Garrett as the originator of this PR should clear things up. cheers. alex > > % 26886 ERRORS > % 26887 The nanosleep( ) function shall fail if: > % 26888 [EINTR] The nanosleep( ) function was > interrupted by a signal. > % 26889 [EINVAL] The rqtp argument specified a > nanosecond value less than zero or greater than > % 26890 or equal to 1000 million. > > It just specifies EINVAL for out-of-bounds nanoseconds values because those > give an invalid timeval. Negative values for the seconds field are valid > if they are representable. > > A negative sleep time is equally physically impossible as a sleep time > of 0, but I haven't seen any proposals to break the latter. But if you > want full breakage, be sure to disallow both negative timevals and ones > longer than the lifetime of the universe ;-). > > In private or maybe public old mail about this, I pointed out bugs in > itimerfix() and itimespecfix(). These functions do generate EINVAL > for negative times and are very broken for large positive values > considerably shorter than the lifetime of the universe for 32-bit > time_t's but considerably longer than the lifetime of the universe for > 64-bit time_t's. Callers depend on the time_t's being considerably > less than the time until the time_t's wrap around. This used ti be > avoided (until 2035 for 32-bit signed time_t's) by restricting the > time_t's to 1000 million seconds (3+ years) in itimerfix(). This has > been broken, so anyone who can make syscalls that use itimers can cause > overflows in the kernel. Limiting the maximum itimer to 100 million > seconds or even the lifetime of the univers is not supported by POSIX, > but it is what BSD always did until FreeBSD broke it. itimerfix() and > itimespecfix() also do bogus rounding up to a multiple of the timer > granularity. This is mostly cosmetic, but breaks syscalls that return > residual times. itimespecfix() also has a namespace error. It corresponds > to itimerfix(). There is no itimevalfix(), but there is a confusingly > similar timevalfix(). > > These bugs don't directly affect nanosleep(), since it doesn't use > itimespecfix(), perhaps intentionally to avoid breaking it for negative > times. Its overflow bugs bugs are smaller in nanosleep(), since it > loops internally to handle large times and its algorithm of comparing > the current time with the end time in case it wakes up early is fairly > robust. However, it blindly adds timespecs using timespecadd(&ts, > rqt), where ts is initially the current time (spec) and *rqt is the > arg, and ts is finally the end time. *rqt must be limited to prevent > overflow of this. The usual (but broken) limit of 100 million seconds > would work (until 2035) as elsewhere. When overflow occurs, the result > is undefined. The actual behaviour is normally a garbage negative end > time in ts, and although there are lots of compensating overflows > (adding and subtracting the current time), I think the logic isn't all > accidentally correct throughout. > > Bruce -- a13x From owner-freebsd-standards@FreeBSD.ORG Thu Feb 24 16:57:46 2011 Return-Path: Delivered-To: standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B90E81065672; Thu, 24 Feb 2011 16:57:46 +0000 (UTC) (envelope-from Mark.Martinec@ijs.si) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by mx1.freebsd.org (Postfix) with ESMTP id 34EE68FC18; Thu, 24 Feb 2011 16:57:46 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 2E0441D1D2D; Thu, 24 Feb 2011 17:38:31 +0100 (CET) Authentication-Results: mail.ijs.si; dkim=pass (1024-bit key) header.i=@ijs.si header.b=fEcUUZo+; dkim-adsp=pass DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= message-id:content-transfer-encoding:content-type:content-type :mime-version:in-reply-to:references:user-agent:date:date :subject:subject:organization:from:from:received:received :received:vbr-info; s=jakla2; t=1298565508; x=1301157509; bh=AFb yzLUMpVNfENtg0PJx6MvIyJzYpii48LrI+i8mvFo=; b=fEcUUZo+EPxdTxi84f0 jyGG5sn0PLMlTV99guYRSbn+xnCD/h9xRrRnJchQRpp/T5bpmub5uLRCNk4obB02 ZE3UQPNDAss6GLcZcMXJANewiyDvehxEHhWS2xNMKmDAy80T0jYeC+xJF9nzbTYj UBBWqhqSWBhRfvaH4OQ9+hyw= VBR-Info: md=ijs.si; mc=all; mv=dwl.spamhaus.org; X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([127.0.0.1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [127.0.0.1]) (amavisd-new, port 10012) with ESMTP id oAFwczDBJifB; Thu, 24 Feb 2011 17:38:28 +0100 (CET) Received: from edina.ijs.si (unknown [IPv6:2001:1470:ff80:0:2e0:81ff:fe72:51d]) by mail.ijs.si (Postfix) with ESMTP; Thu, 24 Feb 2011 17:38:28 +0100 (CET) Received: from neli.ijs.si (neli.ijs.si [193.2.4.95]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by edina.ijs.si (Postfix) with ESMTPSA id 46E3122F48D; Thu, 24 Feb 2011 17:38:28 +0100 (CET) From: Mark Martinec Organization: J. Stefan Institute To: John Hein Date: Thu, 24 Feb 2011 17:38:27 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RELEASE-p2; KDE/4.5.5; amd64; ; ) References: <201102190306.p1J36Vfs069799@red.freebsd.org> <19814.34778.150762.44030@gromit.timing.com> In-Reply-To: <19814.34778.150762.44030@gromit.timing.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201102241738.28051.Mark.Martinec@ijs.si> Cc: standards@freebsd.org, freebsd-gnats-submit@freebsd.org Subject: Re: standards/154873: ZFS violates POSIX on open/O_CREAT -> ftruncate 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, 24 Feb 2011 16:57:46 -0000 > Mark Martinec wrote at 03:06 +0000 on Feb 19, 2011: > > Error truncating: Permission denied > > when (cwd) on a ZFS file system, but will pass clean > > when on UFS or on some other file system. > > The test gets 'Error truncating: Permission denied' on nfs also > (tested with freebsd implementation of v3). > Have you checked with the fs@ mailing list? I sent a copy of this PR to the freebsd-fs@freebsd.org mailing list, with no response so far ... Mark From owner-freebsd-standards@FreeBSD.ORG Thu Feb 24 17:00:22 2011 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 564651065697 for ; Thu, 24 Feb 2011 17:00:22 +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 44C568FC0C for ; Thu, 24 Feb 2011 17:00:22 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p1OH0LrK086014 for ; Thu, 24 Feb 2011 17:00:21 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p1OH0LSW085989; Thu, 24 Feb 2011 17:00:21 GMT (envelope-from gnats) Date: Thu, 24 Feb 2011 17:00:21 GMT Message-Id: <201102241700.p1OH0LSW085989@freefall.freebsd.org> To: freebsd-standards@FreeBSD.org From: Mark Martinec Cc: Subject: Re: standards/154873: ZFS violates POSIX on open/O_CREAT -> ftruncate X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mark Martinec List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 17:00:22 -0000 The following reply was made to PR standards/154873; it has been noted by GNATS. From: Mark Martinec To: John Hein Cc: freebsd-gnats-submit@freebsd.org, standards@freebsd.org Subject: Re: standards/154873: ZFS violates POSIX on open/O_CREAT -> ftruncate Date: Thu, 24 Feb 2011 17:38:27 +0100 > Mark Martinec wrote at 03:06 +0000 on Feb 19, 2011: > > Error truncating: Permission denied > > when (cwd) on a ZFS file system, but will pass clean > > when on UFS or on some other file system. > > The test gets 'Error truncating: Permission denied' on nfs also > (tested with freebsd implementation of v3). > Have you checked with the fs@ mailing list? I sent a copy of this PR to the freebsd-fs@freebsd.org mailing list, with no response so far ... Mark From owner-freebsd-standards@FreeBSD.ORG Sat Feb 26 18:30:44 2011 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 CD108106566B; Sat, 26 Feb 2011 18:30:44 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id B08778FC08; Sat, 26 Feb 2011 18:30:44 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id p1QIUige092782; Sat, 26 Feb 2011 10:30:44 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id p1QIUila092781; Sat, 26 Feb 2011 10:30:44 -0800 (PST) (envelope-from sgk) Date: Sat, 26 Feb 2011 10:30:44 -0800 From: Steve Kargl To: freebsd-hackers@freebsd.org, freebsd-standards@freebsd.org Message-ID: <20110226183044.GA92706@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: [PATCH] improve accuracy and speed of tanh[f] for x in [0:1) 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, 26 Feb 2011 18:30:45 -0000 The patch that follows my signature improves both the accuracy and speed of tanhf and tanh in the interval [0,1). The testing was done on an Intel Core2 Duo CPU T7250 and everything is compiled with gcc. The improvements are accomplished by using a trancated continued fraction instead of relying on expm1[f] and a rewritten definition of tanh(x). The results can be summarized by | fdlibm | Con. frac. ------------------------------- | ulp time | ulp time tanhf | 1.66 1.36 | 0.56 1.31 tanh | 2.16 5.65 | 1.53 5.33 tanhl | 2.36 4.72 | 1.53 5.12 ulp in the above table is the maximum ulp observed for 2 million evenly distributed values with the interval. The timing for tanhf is for 5 million calls and the timing for tanh is for 20 million calls, where again the values are evenly distributed across the interval. The timings are the total time in seconds for a tight loop. For those paying attention, yes, the last entry is for tanhl, which libm does not currently implement. I have an implementation that uses expm1l and fdlibm's simple rewritten tanh(x) definition. I, of course, have a truncated continued fraction implementation as well. Now for those that are really paying attention, libm does not contain an expm1l. :) -- Steve Index: src/s_tanh.c =================================================================== --- src/s_tanh.c (revision 219046) +++ src/s_tanh.c (working copy) @@ -66,8 +66,33 @@ t = expm1(two*fabs(x)); z = one - two/(t+two); } else { +#if 0 + /* + * In the interval, one has a max ulp of 2.156 for 2M + * evenly distributed values. For timing, 20M call + * gives 5.65 s. + */ t = expm1(-two*fabs(x)); z= -t/(t+two); +#else + /* + * This is a continued fraction representation that + * was truncated at the 10th level and then refractored + * to get rid of the divisions. In the interval, one + * has a max ulp of 1.532 for 2M evenly distributed + * values. For timing, 20M calls give 5.33 s. + */ + double x2, t1, t2, t3, t4, t5; + x2 = x * x; + t1 = 399 + 20 * x2; + t3 = 17 * t1 + (21 + x2) * x2; + t4 = 15 * t3 + t1 * x2; + t5 = 13 * t4 + t3 * x2; + t2 = 99 * t5 + (9 * t4 + t5) * x2; + t3 = 7 * t2 + (11 * t5 + t4 * x2) * x2; + z = x / (1 + x2 / (3 + t3 * x2 / (5 * t3 + t2 * x2))); + return (z); +#endif } /* |x| >= 22, return +-1 */ } else { Index: src/s_tanhf.c =================================================================== --- src/s_tanhf.c (revision 219046) +++ src/s_tanhf.c (working copy) @@ -44,8 +44,29 @@ t = expm1f(two*fabsf(x)); z = one - two/(t+two); } else { +#if 0 + /* + * In the interval, one has a max ulp of 1.66 for 2M + * evenly distributed values. For timing, 5M calls + * give 1.36 s. + */ t = expm1f(-two*fabsf(x)); z= -t/(t+two); +#else + /* + * This is a continued fraction representation that + * was truncated at the 6th level and then refractored + * to get rid of the divisions. In the interval, one + * has a max ulp of 0.559 for 2M evenly distributed + * values. For timing, 5M calls give 1.306 s. + */ + float x2, t1, t2, t3; + x2 = x * x; + t1 = 11 + x2; + t2 = 9 * t1 + x2; + t3 = 7 * t2 + t1 * x2; + z = x / (1 + x2 / (3 + t3 * x2 / (5 * t3 + t2 * x2 ))); +#endif } /* |x| >= 9, return +-1 */ } else {