From owner-freebsd-standards@FreeBSD.ORG Mon May 24 11:01:55 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 4C7D316A4CF for ; Mon, 24 May 2004 11:01:55 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30DDA43D49 for ; Mon, 24 May 2004 11:01:55 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) i4OI1sUp076661 for ; Mon, 24 May 2004 11:01:54 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i4OI1s1a076655 for freebsd-standards@freebsd.org; Mon, 24 May 2004 11:01:54 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 24 May 2004 11:01:54 -0700 (PDT) Message-Id: <200405241801.i4OI1s1a076655@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, 24 May 2004 18:01:55 -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 o [2004/05/13] standards/66608standards sigprocmask() does not work with pthread 11 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/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' & o [2004/05/11] standards/66531standards _gettemp uses a far smaller set of filena 28 problems total. From owner-freebsd-standards@FreeBSD.ORG Tue May 25 08:50:50 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 C616A16A53C for ; Tue, 25 May 2004 08:50:49 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8905143D31 for ; Tue, 25 May 2004 08:50:49 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) i4PFoW5N027762 for ; Tue, 25 May 2004 08:50:32 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i4PFoWEN027761; Tue, 25 May 2004 08:50:32 -0700 (PDT) (envelope-from gnats) Date: Tue, 25 May 2004 08:50:32 -0700 (PDT) Message-Id: <200405251550.i4PFoWEN027761@freefall.freebsd.org> To: freebsd-standards@FreeBSD.org From: Harti Brandt 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: Harti Brandt List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2004 15:50:50 -0000 The following reply was made to PR standards/66357; it has been noted by GNATS. From: Harti Brandt To: "Mark D. Baushke" Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: standards/66357: make POSIX conformance problem ('sh -e' & '+' command-line flag) Date: Tue, 25 May 2004 17:43:07 +0200 (MET DST) [CC's removed] [Sorry for the delay, I just discovered that this is still in my mailbox]. On Mon, 10 May 2004, Mark D. Baushke wrote: > 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'm currently moving jobs and have no access to my link-list, but you should be able to find the mailing lists on the opengroup web page. I know that they are not easy to find - watch for Austing Group. > > > 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. The big problem is things like HDRS=a.h b.h c.h install: for i in $(HDRS) ; do cp $$i /dest ; done If one of the cp's fail, make should abort. That is possible only when doing sh -e. Otherwise a failing cp will just go by unnoticed. What kind of fragility did you see? > 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... There is a long way to get our make POSIX compliant. I think this should be done very careful step by step. I have already one change in the pipe for three months now (standards/57295) - the problem is not to break large numbers of ports, so I really don't want to comnment on the %POSIX stuff atm. Perhaps it would be best to open another PR for this so we don't mix different things. > I look forward to learning what FreeBSD will do. I'll try to move our make in the POSIX direction, but, as I said this will take some time because make is a very central utility to the system. Let me first get the above PR finished, the I will move on to this one. harti From owner-freebsd-standards@FreeBSD.ORG Tue May 25 12:30: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 3EEB916A4D0 for ; Tue, 25 May 2004 12:30:44 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2CF0543D2F for ; Tue, 25 May 2004 12:30:44 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) i4PJUPNj054382 for ; Tue, 25 May 2004 12:30:25 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i4PJUPTl054380; Tue, 25 May 2004 12:30:25 -0700 (PDT) (envelope-from gnats) Date: Tue, 25 May 2004 12:30:25 -0700 (PDT) Message-Id: <200405251930.i4PJUPTl054380@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: Tue, 25 May 2004 19:30:44 -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, "Simon J. Gerraty" Subject: Re: standards/66357: make POSIX conformance problem ('sh -e' & '+' command-line flag) Date: Tue, 25 May 2004 12:22:10 -0700 Harti Brandt writes: > [CC's removed] > > [Sorry for the delay, I just discovered that this is still in my mailbox]. > > On Mon, 10 May 2004, Mark D. Baushke wrote: > > > 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'm currently moving jobs and have no access to my link-list, but > you should be able to find the mailing lists on the opengroup web page. > I know that they are not easy to find - watch for Austing Group. > > > > > > 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. > > The big problem is things like > > HDRS=a.h b.h c.h > > install: > for i in $(HDRS) ; do cp $$i /dest ; done > > If one of the cp's fail, make should abort. That is possible only when > doing sh -e. Otherwise a failing cp will just go by unnoticed. If the POSIX user wants your semantics, doing install: for i in $(HDRS) ; do cp $$i /dest || exit 1; done should work and is much more explicit about when and how a failure should occur. > What kind of fragility did you see? Typically, this has been with projects that use POSIX make programs and have fairly non-trivial actions for a given rule. Something like this: failed=0; all=0; xfail=0; xpass=0; skip=0; srcdir=../../lib; export srcdir; list='test-getdate.sh'; if test -n "$list"; then for tst in $list; do if test -f ./$tst; then dir=./; elif test -f $tst; then dir=; else dir="../../lib/"; fi; if ${dir}$tst; then all=`expr $all + 1`; case " " in *" $tst "*) xpass=`expr $xpass + 1`; failed=`expr $failed + 1`; echo "XPASS: $tst"; ;; *) echo "PASS: $tst"; ;; esac; elif test $? -ne 77; then all=`expr $all + 1`; case " " in *" $tst "*) xfail=` expr $xfail + 1`; echo "XFAIL: $tst"; ;; *) failed=`expr $failed + 1`; echo "FAIL: $tst"; ;; esac; else skip=`expr $skip + 1`; echo "SKIP: $tst"; fi; done; if test "$failed" -eq 0; then if test "$xfail" -eq 0; then banner="All $all tests passed"; else banner="All $all tests behaved as expected ($xfail expected failures)"; fi; else if test "$xpass" -eq 0; then banner="$failed of $all tests failed"; else banner="$failed of $all tests did not behave as e! xpected ($xpass unexpected passes)"; fi; fi; dashes="$banner"; skipped=""; if test "$skip" -ne 0; then skipped="($skip tests were not run)"; test `echo "$skipped" | wc -c` -gt `echo "$banner" | wc -c` && dashes="$skipped"; fi; report=""; if test "$failed" -ne 0 && test -n "bug-LIST@LIST.org"; then report="Please report to bug-LIST@LIST.org"; test `echo "$report" | wc -c` -gt `echo "$banner" | wc -c` && dashes="$report"; fi; dashes=`echo "$dashes" | sed s/./=/g`; echo "$dashes"; echo "$ba nner"; test -n "$skipped" && echo "$skipped"; test -n "$report" && echo "$report"; echo "$dashes"; test "$failed" -eq 0; else :; fi which the automake folks had used in one of their templates. > > 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... > > There is a long way to get our make POSIX compliant. I think this should > be done very careful step by step. I have already one change in the pipe > for three months now (standards/57295) - the problem is not to break large > numbers of ports, so I really don't want to comnment on the %POSIX stuff > atm. Perhaps it would be best to open another PR for this so we don't mix > different things. Okay, I'll try to report it sometime next week (after the holiday). > > I look forward to learning what FreeBSD will do. > > I'll try to move our make in the POSIX direction, but, as I said this will > take some time because make is a very central utility to the system. > > Let me first get the above PR finished, the I will move on to this one. > > harti With regard to 57295, I was under the impression that .MAKEFLAGS was not part of the POSIX standard, but that MAKEFLAGS is. I believe that the suggested patch modifies the .MAKEFLAGS variable... Of course, the other interesting problem is that there are still '#ifdef POSIX' fragments laying around in the /usr/src/usr.bin/make tree to confuse the issue. I do understand it may take time to get this stuff fixed, but I do think it is a good design goal. Thank you, -- Mark