From owner-freebsd-standards@FreeBSD.ORG Sun May 9 04:44:10 2004 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB36C16A4CE; Sun, 9 May 2004 04:44:10 -0700 (PDT) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44E6443D53; Sun, 9 May 2004 04:44:07 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])i49Bi64u006174; Sun, 9 May 2004 21:44:06 +1000 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i49Bi3I2017082; Sun, 9 May 2004 21:44:04 +1000 Date: Sun, 9 May 2004 21:44:03 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: David Schultz In-Reply-To: <20040508225838.GA15663@VARK.homeunix.com> Message-ID: <20040509201148.P8241@gamplex.bde.org> References: <20040508194748.GN29712@wombat.fafoe.narf.at> <20040508225838.GA15663@VARK.homeunix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-standards@freebsd.org Subject: Re: Fixing ilogb() X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2004 11:44:10 -0000 On Sat, 8 May 2004, David Schultz wrote: > On Sat, May 08, 2004, Stefan Farfeleder wrote: > > I found two problems with our current ilogb() implemenation(s). > > > > - Both the man page and FP_ILOGB0 claim that ilogb(0) returns INT_MIN > > while the implementation in s_ilogb.c returns -INT_MAX. We really > > have to decide on one value (both are conforming to C99, I've attached > > the text). The attached patch assumes that -INT_MAX is kept. > > FWIW, SunOS has historically used the following mapping: > > ilogb(0) ==> -INT_MAX > ilogb(NAN) ==> INT_MAX > ilogb(INFINITY) ==> INT_MAX > > This matches OS X, our MI ilogb() implementation[1], and your > patch, and I think those are pretty good reasons to use your > version. I agree. > > On a related note, is there a reason why doesn't use > > 's __INT_M{AX,IN} for the FP_ILOGB* macros? > > Yes, machine/_limits.h did not exist when it was written, so there > was no way to get INT_{MIN,MAX} without namespace pollution. > It would be a good idea to use these in math.h and s_ilogb[f].c now. It would also be good to keep using fdlibm's code, but the hard-coded INT_{MIN,MAX} are too vax-dependent. > > - On i386 the assembler file s_ilogb.S is used instead. It uses the > > instruction fxtract which returns INT_MIN for 0, infinity and NaN. > > Except for infinity this conforms too, but doesn't play well with our > > MI definitions for FP_ILOGB*. In the attached patch I've aligned > > s_ilogb.S's behaviour with s_ilogb.c, the alternative would be just > > fixing infinity and making FP_ILOGB* MD. > > Although it would be legitimate to make FP_ILOGB* MD, we have to > fix the infinity case anyway, so we might as well make the NAN and > 0 cases MI. > > FWIW, I was working on some faster MD implementations of > fpclassify() and friends a while ago, and getting these corner > cases to be consistent is a big PITA. ;-) It also has unfortunate runtime overheads. Returning INT_MIN for the i387 version of ilogb(Inf) was from overflow. fxtract(Inf) gives Inf, but fistpl(Inf) gives INT_MIN since a preposterous value is the closest approximation to a NaN that can be represented in an int. === Related bugs === gcc still gets most conversions from large values to longs and longs wrong because it doesn't understand this. E.g.: %%% * constant 1e25 converted to long long = 0x7fffffffffffffff * constant 1e25 converted to unsigned long long = 0x7fffffffffffffff * variable 1e25 converted to long long = 0x8000000000000000 * variable 1e25 converted to unsigned long long = 0x1614014800000000 * constant Inf converted to long long = 0x7fffffffffffffff * constant Inf converted to unsigned long long = 0x7fffffffffffffff * variable Inf converted to long long = 0x8000000000000000 * variable Inf converted to unsigned long long = 0 %%% Here: - the first conversion is reasonable (LLONG_MAX is a reasonable approx. for Inf as a long long) - the second not so reasonable (should be ULLONG_MAX to match the first) - the third is reasonable (LLONG_MIN is a reasonable approx. for NaN as a long long) but inconsistent with the first. - the fourth is garbage - the fifth, sixth and seventh are consistent with the first, second and third, respectively - the eigth is different garbage than the fourth. Negative large values and Infs give different behaviour (slightly better, but not the negatives of the above results). Conversions to longs and unsigned longs give different behaviour (sightly worse, starting with conversion of Inf to -1L). The bugs used to be worse. Typically, gcc would use fistpq for runtime conversions to avoid certain problems and then not understand what to do with the overflow indicator 0x8000000000000000 when converting to a long. Compile-time conversions can use infinite precision so they tend not to be bug for bug compatible, but they now are except for the fourth and eight cases above. Of course, all these are not incorrect, since the behaviour is undefined. I prefer a SIGFPE. === End Related bugs === % Index: src/lib/msun/i387/s_ilogb.S % =================================================================== % RCS file: /usr/home/ncvs/src/lib/msun/i387/s_ilogb.S,v % retrieving revision 1.8 % diff -u -r1.8 s_ilogb.S % --- src/lib/msun/i387/s_ilogb.S 6 Jun 2000 12:12:36 -0000 1.8 % +++ src/lib/msun/i387/s_ilogb.S 8 May 2004 18:57:27 -0000 % @@ -43,11 +43,27 @@ % subl $4,%esp % % fldl 8(%ebp) % + fxam % + fnstsw %ax % + sahf This is the main runtime overhead. I think it can mostly be avoided by checking the return value. ilogb() can only be INT_MIN after overflow or other conversion errors (check this). There 3 cases: - logb(0) = -Inf; fistpl(-Inf) = INT_MIN + IE - logb(Inf) = Inf; fistpl(-Inf) = INT_MIN + IE - logb(NaN) = same NaN; fistpl(NaN) = INT_MIN + IE After finding one of these rare cases, the exact case still needs to be determined by looking at the original value or the result of fxtract. Then fucom with 0 should be a faster way to do the classification. A full classification is not needed sice denormals are not special here and unsupported formats are unsupported here too. % + jc .L2 % + jnp .L3 % + Style bugs: space instead of tab. % fxtract % fstp %st % % fistpl -4(%ebp) % movl -4(%ebp),%eax % - % +.L1: Style bug: the blank line is more needed than before. % leave % ret % + % +.L2: % + /* Depending on ilogb(NAN) == ilogb(INFINITY) */ Better wordingi and punctuation: "This depends on ... .". I would prefer an unambigous value for NaNs. % + movl $0x7fffffff,%eax /* FP_ILOGBNAN, INT_MAX */ Style bugs: some comments could be improved, but won't be needed when is used. % + fstp %st Style bug: %st(0) is normal style in this directory except in this file and s_logb,S, % + jmp .L1 Style bug: a blank line is needed more here than elsewhere. % +.L3: % + movl $0x80000001,%eax /* FP_ILOGB0 */ % + fstp %st % + jmp .L1 Bruce From owner-freebsd-standards@FreeBSD.ORG Sun May 9 23:02:51 2004 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C2B316A4CE; Sun, 9 May 2004 23:02:51 -0700 (PDT) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45DF843D31; Sun, 9 May 2004 23:02:50 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])i4A62n5v007987; Mon, 10 May 2004 16:02:49 +1000 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i4A62lHW011465; Mon, 10 May 2004 16:02:47 +1000 Date: Mon, 10 May 2004 16:02:46 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: David Schultz In-Reply-To: <20040509201148.P8241@gamplex.bde.org> Message-ID: <20040510155514.L1063@gamplex.bde.org> References: <20040508194748.GN29712@wombat.fafoe.narf.at> <20040509201148.P8241@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-standards@freebsd.org Subject: Re: Fixing ilogb() X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2004 06:02:51 -0000 On Sun, 9 May 2004, I wrote: > ... > % @@ -43,11 +43,27 @@ > % subl $4,%esp > % > % fldl 8(%ebp) > % + fxam > % + fnstsw %ax > % + sahf > > This is the main runtime overhead. I think it can mostly be avoided by > checking the return value. ilogb() can only be INT_MIN after overflow > or other conversion errors (check this). There 3 cases: > - logb(0) = -Inf; fistpl(-Inf) = INT_MIN + IE > - logb(Inf) = Inf; fistpl(-Inf) = INT_MIN + IE > - logb(NaN) = same NaN; fistpl(NaN) = INT_MIN + IE > After finding one of these rare cases, the exact case still needs to be > determined by looking at the original value or the result of fxtract. > Then fucom with 0 should be a faster way to do the classification. A > full classification is not needed sice denormals are not special here > and unsupported formats are unsupported here too. Another thing to decide is whether the exception flags should be set (or not) to indicate overflow. I think they should be. Checking after doing the operation sets them; checking before does not. The standard is not clear. It says that the result is equivalent to (int)logb() for the non-overflowing cases but has special rules with unusual wording for the overflowing cases. It says "If x is zero they [the ilogb functions] compute the value FP_ILOGB0. ..." Computation a constant value is different from returning it, so this can be interpreted as saying that the exception flags may be set. I think there's a meta-rule that math functions set execption flags where appropriate. Bruce From owner-freebsd-standards@FreeBSD.ORG Sun May 9 23:45:53 2004 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D049616A4CE for ; Sun, 9 May 2004 23:45:53 -0700 (PDT) Received: from VARK.homeunix.com (adsl-68-124-137-57.dsl.pltn13.pacbell.net [68.124.137.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 283FE43D2D for ; Sun, 9 May 2004 23:45:53 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: from VARK.homeunix.com (localhost [127.0.0.1]) by VARK.homeunix.com (8.12.10/8.12.10) with ESMTP id i4A6jbAd023913; Sun, 9 May 2004 23:45:37 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.homeunix.com (8.12.10/8.12.10/Submit) id i4A6jbr1023910; Sun, 9 May 2004 23:45:37 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Date: Sun, 9 May 2004 23:45:32 -0700 From: David Schultz To: Bruce Evans Message-ID: <20040510064532.GB23610@VARK.homeunix.com> Mail-Followup-To: Bruce Evans , freebsd-standards@FreeBSD.ORG References: <20040508194748.GN29712@wombat.fafoe.narf.at> <20040508225838.GA15663@VARK.homeunix.com> <20040509201148.P8241@gamplex.bde.org> <20040510155514.L1063@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040510155514.L1063@gamplex.bde.org> cc: freebsd-standards@FreeBSD.ORG Subject: Re: Fixing ilogb() X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2004 06:45:53 -0000 On Mon, May 10, 2004, Bruce Evans wrote: > On Sun, 9 May 2004, I wrote: > > > ... > > % @@ -43,11 +43,27 @@ > > % subl $4,%esp > > % > > % fldl 8(%ebp) > > % + fxam > > % + fnstsw %ax > > % + sahf > > > > This is the main runtime overhead. I think it can mostly be avoided by > > checking the return value. ilogb() can only be INT_MIN after overflow > > or other conversion errors (check this). There 3 cases: > > - logb(0) = -Inf; fistpl(-Inf) = INT_MIN + IE > > - logb(Inf) = Inf; fistpl(-Inf) = INT_MIN + IE > > - logb(NaN) = same NaN; fistpl(NaN) = INT_MIN + IE > > After finding one of these rare cases, the exact case still needs to be > > determined by looking at the original value or the result of fxtract. > > Then fucom with 0 should be a faster way to do the classification. A > > full classification is not needed sice denormals are not special here > > and unsupported formats are unsupported here too. > > Another thing to decide is whether the exception flags should be set (or > not) to indicate overflow. I think they should be. Checking after doing > the operation sets them; checking before does not. The standard is not > clear. It says that the result is equivalent to (int)logb() for the > non-overflowing cases but has special rules with unusual wording for > the overflowing cases. It says "If x is zero they [the ilogb functions] > compute the value FP_ILOGB0. ..." Computation a constant value is > different from returning it, so this can be interpreted as saying that > the exception flags may be set. I think there's a meta-rule that math > functions set execption flags where appropriate. ilogb() isn't part of IEEE-754 and it is poorly specified in C99, but it is a proposed addition to the next revision of 754, namely IEEE-754R. In that proposal, ilogb() signals no exceptions, except for the automatic invalid exception you get from a signalling NaN. See http://754r.ucbtest.org. (This seems strange, given that logb(0) signals a divide-by-zero exception, but the proposal is quite specific.) From owner-freebsd-standards@FreeBSD.ORG Mon May 10 08:38:10 2004 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D9F116A4CE for ; Mon, 10 May 2004 08:38:10 -0700 (PDT) Received: from bgezal.rise.tuwien.ac.at (bgezal.rise.tuwien.ac.at [128.130.59.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F9CB43D2F for ; Mon, 10 May 2004 08:38:08 -0700 (PDT) (envelope-from stefan@fafoe.narf.at) Received: from fafoe.narf.at (unknown [212.186.3.235]) by bgezal.rise.tuwien.ac.at (Postfix) with ESMTP id DBFCD20AC; Mon, 10 May 2004 17:38:06 +0200 (CEST) Received: from wombat.fafoe.narf.at (wombat.fafoe.narf.at [192.168.1.42]) by fafoe.narf.at (Postfix) with ESMTP id BED1B418B; Mon, 10 May 2004 17:37:45 +0200 (CEST) Received: by wombat.fafoe.narf.at (Postfix, from userid 1001) id A6316388; Mon, 10 May 2004 17:37:41 +0200 (CEST) Date: Mon, 10 May 2004 17:37:41 +0200 From: Stefan Farfeleder To: Bruce Evans Message-ID: <20040510153731.GP29712@wombat.fafoe.narf.at> Mail-Followup-To: Bruce Evans , freebsd-standards@freebsd.org References: <20040508194748.GN29712@wombat.fafoe.narf.at> <20040508225838.GA15663@VARK.homeunix.com> <20040509201148.P8241@gamplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="8tUgZ4IE8L4vmMyh" Content-Disposition: inline In-Reply-To: <20040509201148.P8241@gamplex.bde.org> User-Agent: Mutt/1.5.6i cc: freebsd-standards@freebsd.org Subject: Re: Fixing ilogb() X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2004 15:38:10 -0000 --8tUgZ4IE8L4vmMyh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, May 09, 2004 at 09:44:03PM +1000, Bruce Evans wrote: > % Index: src/lib/msun/i387/s_ilogb.S > % =================================================================== > % RCS file: /usr/home/ncvs/src/lib/msun/i387/s_ilogb.S,v > % retrieving revision 1.8 > % diff -u -r1.8 s_ilogb.S > % --- src/lib/msun/i387/s_ilogb.S 6 Jun 2000 12:12:36 -0000 1.8 > % +++ src/lib/msun/i387/s_ilogb.S 8 May 2004 18:57:27 -0000 > % @@ -43,11 +43,27 @@ > % subl $4,%esp > % > % fldl 8(%ebp) > % + fxam > % + fnstsw %ax > % + sahf > > This is the main runtime overhead. I think it can mostly be avoided by > checking the return value. ilogb() can only be INT_MIN after overflow > or other conversion errors (check this). There 3 cases: > - logb(0) = -Inf; fistpl(-Inf) = INT_MIN + IE > - logb(Inf) = Inf; fistpl(-Inf) = INT_MIN + IE > - logb(NaN) = same NaN; fistpl(NaN) = INT_MIN + IE > After finding one of these rare cases, the exact case still needs to be > determined by looking at the original value or the result of fxtract. > Then fucom with 0 should be a faster way to do the classification. A > full classification is not needed sice denormals are not special here > and unsupported formats are unsupported here too. Thanks for your comments, Bruce. A revised patch is attached, it only adds two instructions in the common case. > % + movl $0x7fffffff,%eax /* FP_ILOGBNAN, INT_MAX */ > > Style bugs: some comments could be improved, but won't be needed when > is used. Unfortunately cannot be included for FP_ILOGB{0,NAN}, so I've duplicated those #defines for now. Any suggestions? Move them to another/new header instead? Cheers, Stefan --8tUgZ4IE8L4vmMyh Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="s_ilogb.S.diff" Index: src/lib/msun/i387/s_ilogb.S =================================================================== RCS file: /usr/home/ncvs/src/lib/msun/i387/s_ilogb.S,v retrieving revision 1.8 diff -I.svn -u -r1.8 s_ilogb.S --- src/lib/msun/i387/s_ilogb.S 6 Jun 2000 12:12:36 -0000 1.8 +++ src/lib/msun/i387/s_ilogb.S 10 May 2004 15:24:43 -0000 @@ -33,10 +33,15 @@ * J.T. Conklin (jtc@wimsey.com), Winning Strategies, Inc. */ +#include #include RCSID("$FreeBSD: src/lib/msun/i387/s_ilogb.S,v 1.8 2000/06/06 12:12:36 bde Exp $") +#define FP_ILOGB0 (-__INT_MAX) +#define FP_ILOGBNAN __INT_MAX +#define FP_ILOGBINF __INT_MAX + ENTRY(ilogb) pushl %ebp movl %esp,%ebp @@ -44,10 +49,35 @@ fldl 8(%ebp) fxtract - fstp %st + fstp %st(0) fistpl -4(%ebp) movl -4(%ebp),%eax + /* fistpl yields __INT_MIN for NaN, Inf and 0. */ + cmpl $__INT_MIN,%eax + je .L2 + +.L1: leave ret + +.L2: + fldl 8(%ebp) + fldz + fucompp + fnstsw %ax + sahf + jp .L3 + jz .L4 + + movl $FP_ILOGBINF,%eax + jmp .L1 + +.L3: + movl $FP_ILOGBNAN,%eax + jmp .L1 + +.L4: + movl $FP_ILOGB0,%eax + jmp .L1 --8tUgZ4IE8L4vmMyh-- From owner-freebsd-standards@FreeBSD.ORG Mon May 10 09:13:14 2004 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9768216A4CE; Mon, 10 May 2004 09:13:14 -0700 (PDT) Received: from colo-dns-ext2.juniper.net (colo-dns-ext2.juniper.net [207.17.137.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB75943D5E; Mon, 10 May 2004 09:13:13 -0700 (PDT) (envelope-from mdb@juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) i4AGD8Bm082419; Mon, 10 May 2004 09:13:08 -0700 (PDT) (envelope-from mdb@juniper.net) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i4AGD8J76966; Mon, 10 May 2004 09:13:08 -0700 (PDT) (envelope-from mdb@juniper.net) To: harti@FreeBSD.ORG In-reply-to: Mail from Harti Brandt dated Sat, 08 May 2004 15:43:45 +0200 <20040508153845.U641@130-149-145-63.dialup.cs.tu-berlin.de> References: <11525.1083948957@juniper.net> <20040508153845.U641@130-149-145-63.dialup.cs.tu-berlin.de> From: "Mark D. Baushke" X-Mailer: MH-E 7.4.3+cvs; nmh 1.0.4; GNU Emacs 21.1.1 X-Face: #8D_6URD2G%vC.hzU Sender: mdb@juniper.net cc: freebsd-standards@FreeBSD.ORG cc: FreeBSD-gnats-submit@FreeBSD.ORG cc: "Simon J. Gerraty" cc: Paul Eggert Subject: Re: standards/66357: make POSIX conformance problem ('sh -e' & '+' command-line flag) X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2004 16:13:14 -0000 Harti Brandt writes: > On Fri, 7 May 2004, Mark D. Baushke wrote: > > > > > >Number: 66357 > > >Category: standards > > >Synopsis: make POSIX conformance problem ('sh -e' & '+' command-line) ... > > >Description: > > Background: > > > > POSIX 1003.2-1997 states that each makefile command line is processed > > as if given to system(3) (see URL > > http://www.opengroup.org/onlinepubs/009695399/utilities/make.html) > > > > POSIX 1003.1-2004 (as well as older versions of the standard) states > > that system() does not use the "sh -e" command to exit immediately if > > any untested command fails in non-interactive mode. (see URL > > http://www.opengroup.org/onlinepubs/009695399/functions/system.html) ... > > The 'sh -e' servers a purpose if you have a more > complicated shell line say a loop. Without -e make will > not stop even if there is an error in an inner command of > a shell loop, while with -e it will exit. I'd say that not > using -e is a posix-bug, not a feature and, in fact, there > has been thoughts on the austin group mailing list to > review this. If you have any particular URLs for those austin group mailing list threads, I would be interested in reading them. I tried to do a quick google search and did not meet with success to finding such a discussion. > I'd think even if we remove the -e in the posix case, we > must retain it in the non-posix case. fwiw: I have found the 'sh -e' feature to be fragile and more likely to do the wrong thing in a complicated action rule especially across multiple platforms. I also wonder if you will also have time to consider how to deal with a .POSIX: setting in a Makefile after sys.mk has already apparently been read in and processed including a number of .if defined(%POSIX) macros settings being done already before the first line of the user's Makefile is processed... For example, consider the following Makefile: .POSIX: arflags:;@echo ARFLAGS = ${ARFLAGS}, POSIX = ${%POSIX} the FreeBSD 5.2-RELEASE /usr/share/mk/sys.mk has the conditional: .if defined(%POSIX) ARFLAGS ?= -rv .else ARFLAGS ?= rl .endif but the value that /usr/bin/make will print for ARFLAGS in this case is ARFLAGS = rl, POSIX = 1003.2 rather than the correct POSIX value. It all makes some sense when one understands that sys.mk is read first, but I suspect that most folks trying to use .POSIX: may consider it a bug rather than a feature to need to use '%POSIX=1003.2' as an argument on the 'make' command line since %POSIX may not be set an an environment variable in the shell. I look forward to learning what FreeBSD will do. Thank you for your consideration of these problems. -- Mark From owner-freebsd-standards@FreeBSD.ORG Mon May 10 09:20:27 2004 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FDE916A4CE for ; Mon, 10 May 2004 09:20:27 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D0A543D49 for ; Mon, 10 May 2004 09:20:26 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) i4AGKQNg085413 for ; Mon, 10 May 2004 09:20:26 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i4AGKQ74085412; Mon, 10 May 2004 09:20:26 -0700 (PDT) (envelope-from gnats) Date: Mon, 10 May 2004 09:20:26 -0700 (PDT) Message-Id: <200405101620.i4AGKQ74085412@freefall.freebsd.org> To: freebsd-standards@FreeBSD.org From: "Mark D. Baushke" Subject: Re: standards/66357: make POSIX conformance problem ('sh -e' & '+' command-line flag) X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Mark D. Baushke" List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2004 16:20:27 -0000 The following reply was made to PR standards/66357; it has been noted by GNATS. From: "Mark D. Baushke" To: harti@FreeBSD.ORG Cc: FreeBSD-gnats-submit@FreeBSD.ORG, Paul Eggert , "Simon J. Gerraty" , freebsd-standards@FreeBSD.ORG Subject: Re: standards/66357: make POSIX conformance problem ('sh -e' & '+' command-line flag) Date: Mon, 10 May 2004 09:13:08 -0700 Harti Brandt writes: > On Fri, 7 May 2004, Mark D. Baushke wrote: > > > > > >Number: 66357 > > >Category: standards > > >Synopsis: make POSIX conformance problem ('sh -e' & '+' command-line) ... > > >Description: > > Background: > > > > POSIX 1003.2-1997 states that each makefile command line is processed > > as if given to system(3) (see URL > > http://www.opengroup.org/onlinepubs/009695399/utilities/make.html) > > > > POSIX 1003.1-2004 (as well as older versions of the standard) states > > that system() does not use the "sh -e" command to exit immediately if > > any untested command fails in non-interactive mode. (see URL > > http://www.opengroup.org/onlinepubs/009695399/functions/system.html) ... > > The 'sh -e' servers a purpose if you have a more > complicated shell line say a loop. Without -e make will > not stop even if there is an error in an inner command of > a shell loop, while with -e it will exit. I'd say that not > using -e is a posix-bug, not a feature and, in fact, there > has been thoughts on the austin group mailing list to > review this. If you have any particular URLs for those austin group mailing list threads, I would be interested in reading them. I tried to do a quick google search and did not meet with success to finding such a discussion. > I'd think even if we remove the -e in the posix case, we > must retain it in the non-posix case. fwiw: I have found the 'sh -e' feature to be fragile and more likely to do the wrong thing in a complicated action rule especially across multiple platforms. I also wonder if you will also have time to consider how to deal with a .POSIX: setting in a Makefile after sys.mk has already apparently been read in and processed including a number of .if defined(%POSIX) macros settings being done already before the first line of the user's Makefile is processed... For example, consider the following Makefile: .POSIX: arflags:;@echo ARFLAGS = ${ARFLAGS}, POSIX = ${%POSIX} the FreeBSD 5.2-RELEASE /usr/share/mk/sys.mk has the conditional: .if defined(%POSIX) ARFLAGS ?= -rv .else ARFLAGS ?= rl .endif but the value that /usr/bin/make will print for ARFLAGS in this case is ARFLAGS = rl, POSIX = 1003.2 rather than the correct POSIX value. It all makes some sense when one understands that sys.mk is read first, but I suspect that most folks trying to use .POSIX: may consider it a bug rather than a feature to need to use '%POSIX=1003.2' as an argument on the 'make' command line since %POSIX may not be set an an environment variable in the shell. I look forward to learning what FreeBSD will do. Thank you for your consideration of these problems. -- Mark From owner-freebsd-standards@FreeBSD.ORG Mon May 10 11:01:41 2004 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A657A16A4EF for ; Mon, 10 May 2004 11:01:41 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 641AA43D2D for ; Mon, 10 May 2004 11:01:41 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) i4AI1fu5095863 for ; Mon, 10 May 2004 11:01:41 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i4AI1eKw095858 for freebsd-standards@freebsd.org; Mon, 10 May 2004 11:01:40 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 10 May 2004 11:01:40 -0700 (PDT) Message-Id: <200405101801.i4AI1eKw095858@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-standards@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2004 18:01:41 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- s [2001/01/23] misc/24590 standards timezone function not compatible witn Sin o [2001/03/05] bin/25542 standards /bin/sh: null char in quoted string o [2002/02/25] bin/35307 standards standard include files are not standard c o [2003/03/05] bin/48958 standards The type 'bool' has different sizes for C o [2003/04/21] standards/51209standards [PATCH] add a64l()/l64a/l64a_r functions p [2003/06/05] standards/52972standards /bin/sh arithmetic not POSIX compliant o [2003/07/12] standards/54410standards one-true-awk not POSIX compliant (no exte o [2003/09/15] standards/56906standards Several math(3) functions fail to set err o [2003/12/31] standards/60772standards _Bool and bool should be unsigned o [2004/02/05] standards/62388standards sys/resource.h does not pull in dependenc 10 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- f [1995/01/11] i386/105 standards Distributed libm (msun) has non-standard o [2000/09/24] bin/21519 standards sys/dir.h should be deprecated some more o [2000/12/05] kern/23304 standards POSIX clock_gettime, clock_getres return o [2001/01/16] bin/24390 standards Replacing old dir-symlinks when using /bi s [2001/06/18] kern/28260 standards UIO_MAXIOV needs to be made public o [2001/11/20] standards/32126standards getopt(3) not Unix-98 conformant s [2002/03/18] standards/36076standards Implementation of POSIX fuser command o [2002/06/13] standards/39256standards [v]snprintf aren't POSIX-conformant for s o [2002/07/09] misc/40378 standards stdlib.h gives needless warnings with -an p [2002/08/12] standards/41576standards POSIX compliance of ln(1) o [2002/10/23] standards/44425standards getcwd() succeeds even if current dir has o [2002/12/09] standards/46119standards Priority problems for SCHED_OTHER using p o [2002/12/23] standards/46504standards Warnings in headers o [2003/06/22] standards/53613standards FreeBSD doesn't define EPROTO o [2003/06/24] bin/53682 standards [PATCH] add fuser(1) utitity o [2003/07/24] standards/54809standards pcvt deficits o [2003/07/24] standards/54833standards more pcvt deficits o [2003/07/25] standards/54839standards pcvt deficits o [2003/07/31] standards/55112standards glob.h, glob_t's gl_pathc should be "size o [2003/09/04] standards/56476standards cd9660 unicode support simple hack o [2003/09/27] standards/57295standards [patch] make does not include cmd line va o [2003/10/12] standards/57911standards fnmatch ("[[:alpha:]]","x", FNM_PATHNAME) o [2003/10/29] standards/58676standards grantpt(3) alters storage used by ptsname o [2003/11/29] standards/59797standards Implement C99's round[f]() math fucntions p [2003/12/26] standards/60597standards FreeBSD's /usr/include lacks of cpio.h s [2004/02/14] standards/62858standards malloc(0) not C99 compliant p [2004/02/21] standards/63173standards Patch to add getopt_long_only(3) to libc o [2004/05/07] standards/66357standards make POSIX conformance problem ('sh -e' & 28 problems total. From owner-freebsd-standards@FreeBSD.ORG Tue May 11 09:00:44 2004 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F5EF16A4EF for ; Tue, 11 May 2004 09:00:44 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62C0D43D86 for ; Tue, 11 May 2004 09:00:41 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) i4BG0fLQ070606 for ; Tue, 11 May 2004 09:00:41 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i4BG0fPk070591; Tue, 11 May 2004 09:00:41 -0700 (PDT) (envelope-from gnats) Resent-Date: Tue, 11 May 2004 09:00:41 -0700 (PDT) Resent-Message-Id: <200405111600.i4BG0fPk070591@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, Jim Luther Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D12016A4CE for ; Tue, 11 May 2004 08:52:25 -0700 (PDT) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 998E143D3F for ; Tue, 11 May 2004 08:52:24 -0700 (PDT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.12.11/8.12.11) with ESMTP id i4BFqOmw033699 for ; Tue, 11 May 2004 08:52:24 -0700 (PDT) (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.12.11/8.12.11/Submit) id i4BFqO9P033698; Tue, 11 May 2004 08:52:24 -0700 (PDT) (envelope-from nobody) Message-Id: <200405111552.i4BFqO9P033698@www.freebsd.org> Date: Tue, 11 May 2004 08:52:24 -0700 (PDT) From: Jim Luther To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Subject: standards/66531: _gettemp uses a far smaller set of filenames than documented and doesn't range check inputs X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2004 16:00:44 -0000 >Number: 66531 >Category: standards >Synopsis: _gettemp uses a far smaller set of filenames than documented and doesn't range check inputs >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-standards >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue May 11 09:00:40 PDT 2004 >Closed-Date: >Last-Modified: >Originator: Jim Luther >Release: Mac OS X 10.3.3 >Organization: Apple Computer, Inc. >Environment: Darwin luthji.apple.com 7.3.0 Darwin Kernel Version 7.3.0: Fri Mar 5 14:22:55 PST 2004; root:xnu/xnu-517.3.15.obj~4/RELEASE_PPC Power Macintosh powerpc >Description: _gettemp is the common subroutine used by mktemp(), mkstemp(), mkstemps(), and mkdtemp() to get temporary file names, create temporary files, and create temporary directories. I found a couple of bugs in it: 1 - The suffix length (slen) parameter passed into it is not range changed -- it could be longer than the basename of the path, or it could be negative. This could cause mkstemps() to possibly create a temporary file in the wrong directory if path[strlen(path)] - slen is an 'X" character and the random character chosen happens to match another directory. For example: char template[] = "/X/template"; suffixlen = 9; fd = mkstemps(template, suffixlen); In the current code, the 'X' in the template would be replaced with a random character and if there were a directory in "/" with that character name, a file named "template" would be created in that directory. If slen is negative, it could corrupt memory outside of the path buffer. 2 - If there's a filename collision, it only cycles through a subset of the possible filenames -- it does not try all permutations. The current code increments the characters until it hits the end of the padchar array -- it does not wrap around to the original random character. So, if by chance, this loop in _getttemp(): /* Fill space with random characters */ while (trv >= path && *trv == 'X') { rand = arc4random() % (sizeof(padchar) - 1); *trv-- = padchar[rand]; } happened to get random numbers that replaced all of the 'X' characters with 'z' (the last character in padchar array), the collision code would exit without trying any other filenames. >How-To-Repeat: I used this test program to detect the problem and ensure it is fixed: #include #include #include #include #include #include #include #define XX_MAX 3844 /* maximum on UFS volume (62 * 62) */ //#define XX_MAX 1296 /* maximum on HFS case-insensitive volume (36 * 36) */ int mkstemp_test(void) { char mkstemp_template[] = "/gettemp_test_dir/file_XX"; char template[NAME_MAX]; int i; int fd; i = 0; while ( 1 ) { strcpy(template, mkstemp_template); fd = mkstemp(template); if ( fd >= 0 ) { close(fd); if ( i >= XX_MAX ) { fprintf(stdout, "mkstemp_test failed: created too many files?!?\n"); return ( EXIT_FAILURE ); } } else { if ( i == XX_MAX ) { fprintf(stdout, "mkstemp_test passed\n"); return ( EXIT_SUCCESS ); } else { fprintf(stdout, "mkstemp_test failed when creating file #%d\n", i + 1); return ( EXIT_FAILURE ); } } ++i; } } int mkstemps_test(void) { char mkstemps_template[] = "/gettemp_test_dir/file_XX.test"; char template[NAME_MAX]; int i; int fd; strcpy(template, mkstemps_template); fd = mkstemps(template, 13); if ( fd >= 0 ) { fprintf(stdout, "mkstemps_test failed: should have detected too long suffixlen parameter\n"); return ( EXIT_FAILURE ); } strcpy(template, mkstemps_template); fd = mkstemps(template, -1); if ( fd >= 0 ) { fprintf(stdout, "mkstemps_test failed: should have detected negative suffixlen parameter\n"); return ( EXIT_FAILURE ); } i = 0; while ( 1 ) { strcpy(template, mkstemps_template); fd = mkstemps(template, 5); if ( fd >= 0 ) { close(fd); if ( i >= XX_MAX ) { fprintf(stdout, "mkstemps_test failed: created too many files?!?\n"); return ( EXIT_FAILURE ); } } else { if ( i == XX_MAX ) { fprintf(stdout, "mkstemps_test passed\n"); return ( EXIT_SUCCESS ); } else { fprintf(stdout, "mkstemps_test failed when creating file #%d\n", i + 1); return ( EXIT_FAILURE ); } } ++i; } } int mkdtemp_test(void) { char mkdtemp_template[] = "/gettemp_test_dir/dir_XX"; char template[NAME_MAX]; int i; char *result; i = 0; while ( 1 ) { strcpy(template, mkdtemp_template); result = mkdtemp(template); if ( result != NULL ) { if ( i >= XX_MAX ) { fprintf(stdout, "mkdtemp_test failed: created too many directories?!?\n"); return ( EXIT_FAILURE ); } } else { if ( i == XX_MAX ) { fprintf(stdout, "mkdtemp_test passed\n"); return ( EXIT_SUCCESS ); } else { fprintf(stdout, "mkdtemp_test failed when creating directory #%d\n", i + 1); return ( EXIT_FAILURE ); } } ++i; } } int main (int argc, const char * argv[]) { int err; err = mkdir("/gettemp_test_dir", 0700); if ( err == 0 ) { err = mkstemp_test(); if ( !err ) { err = mkstemps_test(); if ( !err ) { err = mkdtemp_test(); if ( !err ) { exit(EXIT_SUCCESS); } } } } else { fprintf(stderr, "mkdir could not create '/gettemp_test_dir': delete it and try again\n"); } exit(EXIT_FAILURE); } >Fix: Here's the diffs from the patch used to fix this in Mac OS X. The file patched was (using the FreeBSD path) src/lib/libc/stdio/mktemp.c, v 1.28 so the diffs should work for FreeBSD, too. Index: stdio/FreeBSD/mktemp.c =================================================================== RCS file: /cvs/root/Libc/stdio/FreeBSD/mktemp.c,v retrieving revision 1.2 retrieving revision 1.2.44.2 diff -u -d -b -r1.2 -r1.2.44.2 --- mktemp.c 2003/05/20 22:22:42 1.2 +++ mktemp.c 2004/03/16 23:05:15 1.2.44.2 @@ -106,13 +106,14 @@ int domkdir; int slen; { - char *start, *trv, *suffp; + char *start, *trv, *suffp, *carryp; char *pad; struct stat sbuf; int rval; uint32_t rand; + char carrybuf[NAME_MAX]; - if (doopen != NULL && domkdir) { + if ((doopen != NULL && domkdir) || slen < 0) { errno = EINVAL; return (0); } @@ -122,7 +123,7 @@ trv -= slen; suffp = trv; --trv; - if (trv < path) { + if (trv < path || NULL != strchr(suffp, '/')) { errno = EINVAL; return (0); } @@ -134,6 +135,9 @@ } start = trv + 1; + /* save first combination of random characters */ + memcpy(carrybuf, start, suffp - start); + /* * check the target directory. */ @@ -170,14 +174,25 @@ return (errno == ENOENT); /* If we have a collision, cycle through the space of filenames */ - for (trv = start;;) { - if (*trv == '\0' || trv == suffp) - return (0); + for (trv = start, carryp = carrybuf;;) { + /* have we tried all possible permutations? */ + if (trv == suffp) + return (0); /* yes - exit with EEXIST */ pad = strchr(padchar, *trv); - if (pad == NULL || *++pad == '\0') - *trv++ = padchar[0]; - else { - *trv++ = *pad; + if (pad == NULL) { + /* this should never happen */ + errno = EIO; + return (0); + } + /* increment character */ + *trv = (*++pad == '\0') ? padchar[0] : *pad; + /* carry to next position? */ + if (*trv == *carryp) { + /* increment position and loop */ + ++trv; + ++carryp; + } else { + /* try with new name */ break; } } >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-standards@FreeBSD.ORG Thu May 13 05:50:28 2004 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 09C2E16A4CE for ; Thu, 13 May 2004 05:50:28 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id A787443D2F for ; Thu, 13 May 2004 05:50:27 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) i4DCoRRS004975 for ; Thu, 13 May 2004 05:50:27 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i4DCoRH6004971; Thu, 13 May 2004 05:50:27 -0700 (PDT) (envelope-from gnats) Resent-Date: Thu, 13 May 2004 05:50:27 -0700 (PDT) Resent-Message-Id: <200405131250.i4DCoRH6004971@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, Georg Graf Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E329D16A4CE for ; Thu, 13 May 2004 05:46:11 -0700 (PDT) Received: from schurli.wu-wien.ac.at (schurli.wu-wien.ac.at [137.208.16.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 29D9843D3F for ; Thu, 13 May 2004 05:46:11 -0700 (PDT) (envelope-from georg@schurli.wu-wien.ac.at) Received: from schurli.wu-wien.ac.at (localhost [127.0.0.1]) i4DCk6mI094003; Thu, 13 May 2004 14:46:07 +0200 (CEST) (envelope-from georg@schurli.wu-wien.ac.at) Received: (from georg@localhost) by schurli.wu-wien.ac.at (8.12.8p2/8.12.8/Submit) id i4DCk6oR094002; Thu, 13 May 2004 14:46:06 +0200 (CEST) (envelope-from georg) Message-Id: <200405131246.i4DCk6oR094002@schurli.wu-wien.ac.at> Date: Thu, 13 May 2004 14:46:06 +0200 (CEST) From: Georg Graf To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 cc: georg@graf.priv.at Subject: standards/66608: sigprocmask() does not work with pthread X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Georg Graf List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2004 12:50:28 -0000 >Number: 66608 >Category: standards >Synopsis: sigprocmask() does not work with pthread >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-standards >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu May 13 05:50:26 PDT 2004 >Closed-Date: >Last-Modified: >Originator: Georg Graf >Release: FreeBSD 4.8-RELEASE-p13 i386 >Organization: WU >Environment: System: FreeBSD schurli.wu-wien.ac.at 4.8-RELEASE-p13 FreeBSD 4.8-RELEASE-p13 #0: Mon Oct 13 21:12:43 CEST 2003 root@milo.wu-wien.ac.at:/usr/obj/usr/src/sys/ATAPICAM i386 >Description: sigprocmask() fails to block signals in threaded applications >How-To-Repeat: I have setup a page where you can try signal.c and signal_t.c (use the supplied Makefile!) >Fix: Fix requires some hacking and discussion, I assume. I would like to participate in the discussion, if possible! - Thanks! yours, George >Release-Note: >Audit-Trail: >Unformatted: