From owner-freebsd-standards@FreeBSD.ORG Sun Jun 5 19:12:49 2005 Return-Path: X-Original-To: freebsd-standards@freebsd.org 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 E34C316A41C for ; Sun, 5 Jun 2005 19:12:49 +0000 (GMT) (envelope-from liamfoy@sepulcrum.org) Received: from moutvdomng.kundenserver.de (moutvdom.kundenserver.de [212.227.126.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8CF6143D1D for ; Sun, 5 Jun 2005 19:12:47 +0000 (GMT) (envelope-from liamfoy@sepulcrum.org) Received: from [212.227.126.224] (helo=mrvdomng.kundenserver.de) by moutvdomng.kundenserver.de with esmtp (Exim 3.35 #1) id 1Df0YA-0005xN-00 for freebsd-standards@freebsd.org; Sun, 05 Jun 2005 21:12:46 +0200 Received: from host217-42-173-197.range217-42.btcentralplus.com ([217.42.173.197] helo=localhost) by mrvdomng.kundenserver.de with esmtp (Exim 3.35 #1) id 1Df0YA-0003wU-00 for freebsd-standards@freebsd.org; Sun, 05 Jun 2005 21:12:46 +0200 Date: Sun, 5 Jun 2005 20:12:41 +0100 From: "Liam J. Foy" To: freebsd-standards@freebsd.org Message-ID: <20050605191241.GA14672@anarion> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.8i Subject: setmode patches 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, 05 Jun 2005 19:12:50 -0000 Hey guys, I want to show you all some patches: http://metawire.org/~liamfoy/setmode.c.diff.f http://metawire.org/~liamfoy/setmode.3.diff.f This will allow errno to be set in all cases to ERANGE. We can then check this in applications which use setmode(3). Most usage of setmode(3) assumes that that setmode will fail due to an invalid file mode. Example: This snip is from chmod.c: [snip] if (hflag) change_mode = lchmod; else change_mode = chmod; mode = *argv; if ((set = setmode(mode)) == NULL) errx(1, "invalid file mode: %s", mode); if ((ftsp = fts_open(++argv, fts_options, 0)) == NULL) err(1, "fts_open"); for (rval = 0; (p = fts_read(ftsp)) != NULL;) { [snip] However, setmode(3) can fail due to malloc. With the following patch, we can show whether it was actually a bad file mode or something else (malloc): http://metawire.org/~liamfoy/chmod.c.diff.f Anyone have any comments/suggestions? There are also many other instances where setmode is assumed to fail due to a invalid file mode only (I can also create these patches). Cheers, -- - Liam J. Foy liamfoy@sepulcrum.org From owner-freebsd-standards@FreeBSD.ORG Mon Jun 6 11:01:57 2005 Return-Path: X-Original-To: freebsd-standards@freebsd.org 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 16EA216A41C for ; Mon, 6 Jun 2005 11:01:57 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA57843D1F for ; Mon, 6 Jun 2005 11:01:56 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j56B1uEf065710 for ; Mon, 6 Jun 2005 11:01:56 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j56B1u2r065704 for freebsd-standards@freebsd.org; Mon, 6 Jun 2005 11:01:56 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 6 Jun 2005 11:01:56 GMT Message-Id: <200506061101.j56B1u2r065704@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 Cc: Subject: Current problem reports assigned to you 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, 06 Jun 2005 11:01:57 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2001/03/05] bin/25542 standards /bin/sh: null char in quoted string p [2002/02/25] standards/35307standards standard include files are not standard c o [2002/12/13] kern/46239 standards posix semaphore implementation errors 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 [2004/01/01] standards/60772standards _Bool and bool should be unsigned o [2004/11/03] standards/73500standards 'set +o' in /bin/sh does not include unse o [2005/03/03] standards/78357standards getaddrinfo() doesn't appear to support A 9 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/09/24] bin/21519 standards sys/dir.h should be deprecated some more o [2001/01/16] bin/24390 standards Replacing old dir-symlinks when using /bi s [2001/01/24] standards/24590standards timezone function not compatible witn Sin s [2001/06/18] kern/28260 standards UIO_MAXIOV needs to be made public p [2001/11/20] standards/32126standards getopt(3) not Unix-98 conformant o [2002/02/27] misc/35381 standards incorrect floating-point display of large s [2002/03/19] standards/36076standards Implementation of POSIX fuser command o [2002/06/14] standards/39256standards [v]snprintf aren't POSIX-conformant for s o [2002/07/09] kern/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 [2003/07/24] standards/54809standards pcvt deficits o [2003/07/25] 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/05] standards/56476standards cd9660 unicode support simple hack o [2003/10/29] standards/58676standards grantpt(3) alters storage used by ptsname 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/03/29] kern/64875 standards [patch] add a system call: fdatasync() 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 o [2004/08/22] standards/70813standards [PATCH] ls not Posix compliant o [2004/08/26] docs/70985 standards [patch] sh(1): incomplete documentation o o [2004/09/22] standards/72006standards floating point formating in non-C locales o [2005/03/20] standards/79055standards Add an IFS regression test for shells o [2005/03/20] standards/79056standards regex(3) regression tests o [2005/03/21] standards/79067standards /bin/sh should be more intelligent about o [2005/05/20] standards/81287standards [PATCH]: fingerd(8) might send a line not 31 problems total. From owner-freebsd-standards@FreeBSD.ORG Wed Jun 8 07:54:07 2005 Return-Path: X-Original-To: standards@freebsd.org 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 C9DBA16A41C for ; Wed, 8 Jun 2005 07:54:07 +0000 (GMT) (envelope-from mike@reifenberger.com) Received: from mailout11.sul.t-online.com (mailout11.sul.t-online.com [194.25.134.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22E3643D58 for ; Wed, 8 Jun 2005 07:54:04 +0000 (GMT) (envelope-from mike@reifenberger.com) Received: from fwd31.aul.t-online.de by mailout11.sul.t-online.com with smtp id 1DfvNz-00085d-03; Wed, 08 Jun 2005 09:54:03 +0200 Received: from fw.reifenberger.com (XBZcw2ZGQeAVkaPv-HNrQGXfVrTbQDaH30HjyFr8rYcWlR9hKk1esl@[84.152.95.217]) by fwd31.sul.t-online.de with esmtp id 1DfvNk-0LeSlU0; Wed, 8 Jun 2005 09:53:48 +0200 Received: from localhost (mike@localhost) by fw.reifenberger.com (8.13.3/8.13.3/Submit) with ESMTP id j587rFx2029984 for ; Wed, 8 Jun 2005 09:53:15 +0200 (CEST) (envelope-from mike@reifenberger.com) X-Authentication-Warning: fw.reifenberger.com: mike owned process doing -bs Date: Wed, 8 Jun 2005 09:53:15 +0200 (CEST) From: Michael Reifenberger To: standards@freebsd.org Message-ID: <20050608094851.D29843@fw.reifenberger.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-ID: XBZcw2ZGQeAVkaPv-HNrQGXfVrTbQDaH30HjyFr8rYcWlR9hKk1esl@t-dialin.net X-TOI-MSGID: c92042e4-33d8-486f-be4c-2e3ff4679fc3 Cc: Subject: libstand functions not ansi-c compiliant 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, 08 Jun 2005 07:54:07 -0000 Hi, as it seems are a few functions as defined/implemented in libstand not ansi-c compiant: putchar, vprintf, vsprintf. They are defined to return void instead of int. The following patch tries to correct that. Any objections to -commit? Index: printf.c =================================================================== RCS file: /home/ncvs/src/lib/libstand/printf.c,v retrieving revision 1.8 diff -u -r1.8 printf.c --- printf.c 6 Apr 2003 05:25:48 -0000 1.8 +++ printf.c 8 Jun 2005 07:48:23 -0000 @@ -75,11 +75,13 @@ return retval; } -void +int vprintf(const char *fmt, va_list ap) { + int retval; kvprintf(fmt, putchar, NULL, 10, ap); + return(retval); } int @@ -95,13 +97,14 @@ return retval; } -void +int vsprintf(char *buf, const char *cfmt, va_list ap) { int retval; retval = kvprintf(cfmt, NULL, (void *)buf, 10, ap); buf[retval] = '\0'; + return(retval); } /* Index: stand.h =================================================================== RCS file: /home/ncvs/src/lib/libstand/stand.h,v retrieving revision 1.41 diff -u -r1.41 stand.h --- stand.h 17 May 2005 17:46:29 -0000 1.41 +++ stand.h 8 Jun 2005 07:48:24 -0000 @@ -248,9 +248,9 @@ extern char *getdisklabel(const char *, struct disklabel *); extern int printf(const char *fmt, ...) __printflike(1, 2); -extern void vprintf(const char *fmt, __va_list); +extern int vprintf(const char *fmt, __va_list); extern int sprintf(char *buf, const char *cfmt, ...) __printflike(2, 3); -extern void vsprintf(char *buf, const char *cfmt, __va_list); +extern int vsprintf(char *buf, const char *cfmt, __va_list); extern void twiddle(void); @@ -369,7 +369,7 @@ */ extern int getchar(void); extern int ischar(void); -extern void putchar(int); +extern int putchar(int); extern int devopen(struct open_file *, const char *, const char **); extern int devclose(struct open_file *f); extern void panic(const char *, ...) __dead2 __printflike(1, 2); Bye/2 --- Michael Reifenberger, Business Development Manager SAP-Basis, Plaut Consulting Comp: Michael.Reifenberger@plaut.de | Priv: Michael@Reifenberger.com http://www.plaut.de | http://www.Reifenberger.com From owner-freebsd-standards@FreeBSD.ORG Wed Jun 8 10:31:00 2005 Return-Path: X-Original-To: standards@freebsd.org 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 6499216A426 for ; Wed, 8 Jun 2005 10:31:00 +0000 (GMT) (envelope-from stefan@fafoe.narf.at) Received: from fafoe.narf.at (chello213047085026.6.14.vie.surfer.at [213.47.85.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F30743D4C for ; Wed, 8 Jun 2005 10:30:59 +0000 (GMT) (envelope-from stefan@fafoe.narf.at) Received: from wombat.fafoe.narf.at (wombat.fafoe.narf.at [192.168.1.42]) by fafoe.narf.at (Postfix) with ESMTP id F1FC13FA7; Wed, 8 Jun 2005 12:30:51 +0200 (CEST) Received: by wombat.fafoe.narf.at (Postfix, from userid 1001) id 6C05A2DD; Wed, 8 Jun 2005 12:30:47 +0200 (CEST) Date: Wed, 8 Jun 2005 12:30:47 +0200 From: Stefan Farfeleder To: Michael Reifenberger Message-ID: <20050608103045.GC16848@wombat.fafoe.narf.at> Mail-Followup-To: Michael Reifenberger , standards@freebsd.org References: <20050608094851.D29843@fw.reifenberger.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050608094851.D29843@fw.reifenberger.com> User-Agent: Mutt/1.5.9i Cc: standards@freebsd.org Subject: Re: libstand functions not ansi-c compiliant 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, 08 Jun 2005 10:31:00 -0000 On Wed, Jun 08, 2005 at 09:53:15AM +0200, Michael Reifenberger wrote: > Hi, > as it seems are a few functions as defined/implemented in libstand > not ansi-c compiant: putchar, vprintf, vsprintf. > They are defined to return void instead of int. libstand isn't intended to be a standards-compliant C library. I'm afraid I don't see the advantages of your proposed changes. > -void > +int > vprintf(const char *fmt, va_list ap) > { > + int retval; > > kvprintf(fmt, putchar, NULL, 10, ap); retval = kvprintf(fmt, putchar, NULL, 10, ap); > + return(retval); > } > @@ -369,7 +369,7 @@ > */ > extern int getchar(void); > extern int ischar(void); > -extern void putchar(int); > +extern int putchar(int); You can't just change the return type in the header without changing all definitions of putchar(). Stefan From owner-freebsd-standards@FreeBSD.ORG Wed Jun 8 10:53:26 2005 Return-Path: X-Original-To: standards@freebsd.org 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 8F69A16A41C for ; Wed, 8 Jun 2005 10:53:26 +0000 (GMT) (envelope-from mike@reifenberger.com) Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E9F743D48 for ; Wed, 8 Jun 2005 10:53:25 +0000 (GMT) (envelope-from mike@reifenberger.com) Received: from fwd23.aul.t-online.de by mailout03.sul.t-online.com with smtp id 1DfyBY-0001Xo-03; Wed, 08 Jun 2005 12:53:24 +0200 Received: from fw.reifenberger.com (rXRICwZHYergJi3oRnEYROjEFzCncmcyg+RVZF-KVP4EHnMeBh0nUk@[84.152.95.217]) by fwd23.sul.t-online.de with esmtp id 1DfyBH-0ZHU3c0; Wed, 8 Jun 2005 12:53:07 +0200 Received: from localhost (mike@localhost) by fw.reifenberger.com (8.13.3/8.13.3/Submit) with ESMTP id j58AqgXR030627; Wed, 8 Jun 2005 12:52:42 +0200 (CEST) (envelope-from mike@reifenberger.com) X-Authentication-Warning: fw.reifenberger.com: mike owned process doing -bs Date: Wed, 8 Jun 2005 12:52:42 +0200 (CEST) From: Michael Reifenberger To: Stefan Farfeleder In-Reply-To: <20050608103045.GC16848@wombat.fafoe.narf.at> Message-ID: <20050608124306.X30581@fw.reifenberger.com> References: <20050608094851.D29843@fw.reifenberger.com> <20050608103045.GC16848@wombat.fafoe.narf.at> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-ID: rXRICwZHYergJi3oRnEYROjEFzCncmcyg+RVZF-KVP4EHnMeBh0nUk@t-dialin.net X-TOI-MSGID: 3d5fa302-2f53-4a48-b705-8dc12b62b6f9 Cc: standards@freebsd.org Subject: Re: libstand functions not ansi-c compiliant 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, 08 Jun 2005 10:53:26 -0000 On Wed, 8 Jun 2005, Stefan Farfeleder wrote: ... > > libstand isn't intended to be a standards-compliant C library. I'm > afraid I don't see the advantages of your proposed changes. > IMHO this would violate POLA. If the functions are called like standard, they should complay to the standard. The advantage would be (thats how I got to this issue at all) that you don't get compiling errors when including too. (I had to do this to get the definition of FILE for the work on upgrading sys/boot/ficl to ficl4) >> -void >> +int >> vprintf(const char *fmt, va_list ap) >> { >> + int retval; >> >> kvprintf(fmt, putchar, NULL, 10, ap); > > retval = kvprintf(fmt, putchar, NULL, 10, ap); > >> + return(retval); >> } > >> @@ -369,7 +369,7 @@ >> */ >> extern int getchar(void); >> extern int ischar(void); >> -extern void putchar(int); >> +extern int putchar(int); > > You can't just change the return type in the header without changing all > definitions of putchar(). > It seems that putchar is not implemented in libstand. Do you know where? Bye/2 --- Michael Reifenberger, Business Development Manager SAP-Basis, Plaut Consulting Comp: Michael.Reifenberger@plaut.de | Priv: Michael@Reifenberger.com http://www.plaut.de | http://www.Reifenberger.com From owner-freebsd-standards@FreeBSD.ORG Wed Jun 8 12:54:39 2005 Return-Path: X-Original-To: standards@freebsd.org 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 2775C16A41F for ; Wed, 8 Jun 2005 12:54:39 +0000 (GMT) (envelope-from stefan@fafoe.narf.at) Received: from fafoe.narf.at (chello213047085026.6.14.vie.surfer.at [213.47.85.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74AE743D58 for ; Wed, 8 Jun 2005 12:54:38 +0000 (GMT) (envelope-from stefan@fafoe.narf.at) Received: from wombat.fafoe.narf.at (wombat.fafoe.narf.at [192.168.1.42]) by fafoe.narf.at (Postfix) with ESMTP id 54DC53FA7; Wed, 8 Jun 2005 14:54:25 +0200 (CEST) Received: by wombat.fafoe.narf.at (Postfix, from userid 1001) id EA9A12DD; Wed, 8 Jun 2005 14:54:23 +0200 (CEST) Date: Wed, 8 Jun 2005 14:54:23 +0200 From: Stefan Farfeleder To: Michael Reifenberger Message-ID: <20050608125416.GA17962@wombat.fafoe.narf.at> Mail-Followup-To: Michael Reifenberger , standards@freebsd.org References: <20050608094851.D29843@fw.reifenberger.com> <20050608103045.GC16848@wombat.fafoe.narf.at> <20050608124306.X30581@fw.reifenberger.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050608124306.X30581@fw.reifenberger.com> User-Agent: Mutt/1.5.9i Cc: standards@freebsd.org Subject: Re: libstand functions not ansi-c compiliant 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, 08 Jun 2005 12:54:39 -0000 On Wed, Jun 08, 2005 at 12:52:42PM +0200, Michael Reifenberger wrote: > > The advantage would be (thats how I got to this issue at all) that > you don't get compiling errors when including too. > (I had to do this to get the definition of FILE for the work > on upgrading sys/boot/ficl to ficl4) I'd consider including from sys/boot/ficl a bug. > >You can't just change the return type in the header without changing all > >definitions of putchar(). > > It seems that putchar is not implemented in libstand. > Do you know where? Each application using libstand is expected to implement putchar(), see libstand(3). Stefan From owner-freebsd-standards@FreeBSD.ORG Wed Jun 8 13:32:51 2005 Return-Path: X-Original-To: standards@freebsd.org 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 1BCAD16A41C for ; Wed, 8 Jun 2005 13:32:51 +0000 (GMT) (envelope-from mike@reifenberger.com) Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0FFA43D58 for ; Wed, 8 Jun 2005 13:32:50 +0000 (GMT) (envelope-from mike@reifenberger.com) Received: from fwd21.aul.t-online.de by mailout06.sul.t-online.com with smtp id 1Dg0fo-0002Wf-04; Wed, 08 Jun 2005 15:32:48 +0200 Received: from fw.reifenberger.com (XH9M02ZEreT1+OOAIaina0xmiXx9S3g1yqPw2QOiSwpoTcHuLX8CQ-@[84.152.95.217]) by fwd21.sul.t-online.de with esmtp id 1Dg0fa-1GqdTU0; Wed, 8 Jun 2005 15:32:34 +0200 Received: from localhost (mike@localhost) by fw.reifenberger.com (8.13.3/8.13.3/Submit) with ESMTP id j58DW9pI031307; Wed, 8 Jun 2005 15:32:09 +0200 (CEST) (envelope-from mike@reifenberger.com) X-Authentication-Warning: fw.reifenberger.com: mike owned process doing -bs Date: Wed, 8 Jun 2005 15:32:09 +0200 (CEST) From: Michael Reifenberger To: Stefan Farfeleder In-Reply-To: <20050608125416.GA17962@wombat.fafoe.narf.at> Message-ID: <20050608152614.H31265@fw.reifenberger.com> References: <20050608094851.D29843@fw.reifenberger.com> <20050608103045.GC16848@wombat.fafoe.narf.at> <20050608124306.X30581@fw.reifenberger.com> <20050608125416.GA17962@wombat.fafoe.narf.at> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-ID: XH9M02ZEreT1+OOAIaina0xmiXx9S3g1yqPw2QOiSwpoTcHuLX8CQ-@t-dialin.net X-TOI-MSGID: e31d3ea8-7ecf-4793-82e8-1a9da623f62b Cc: standards@freebsd.org Subject: Re: libstand functions not ansi-c compiliant 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, 08 Jun 2005 13:32:51 -0000 On Wed, 8 Jun 2005, Stefan Farfeleder wrote: > Date: Wed, 8 Jun 2005 14:54:23 +0200 > From: Stefan Farfeleder > To: Michael Reifenberger > Cc: standards@freebsd.org > Subject: Re: libstand functions not ansi-c compiliant > > On Wed, Jun 08, 2005 at 12:52:42PM +0200, Michael Reifenberger wrote: >> >> The advantage would be (thats how I got to this issue at all) that >> you don't get compiling errors when including too. >> (I had to do this to get the definition of FILE for the work >> on upgrading sys/boot/ficl to ficl4) > > I'd consider including from sys/boot/ficl a bug. > Maybe. Thats debatable. But by default ficl.h (coming with ficl4)does inslude and ficl4 says about itself: ...Ficl is written in strict ANSI C... Unfortunately is part of ANSI-C... So one cant blame ficl4 for that. >>> You can't just change the return type in the header without changing all >>> definitions of putchar(). >> >> It seems that putchar is not implemented in libstand. >> Do you know where? > > Each application using libstand is expected to implement putchar(), see > libstand(3). > Ah. Bye/2 --- Michael Reifenberger, Business Development Manager SAP-Basis, Plaut Consulting Comp: Michael.Reifenberger@plaut.de | Priv: Michael@Reifenberger.com http://www.plaut.de | http://www.Reifenberger.com From owner-freebsd-standards@FreeBSD.ORG Wed Jun 8 16:41:49 2005 Return-Path: X-Original-To: standards@freebsd.org 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 23B0216A41C for ; Wed, 8 Jun 2005 16:41:49 +0000 (GMT) (envelope-from stefan@fafoe.narf.at) Received: from fafoe.narf.at (chello213047085026.6.14.vie.surfer.at [213.47.85.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id B737243D48 for ; Wed, 8 Jun 2005 16:41:48 +0000 (GMT) (envelope-from stefan@fafoe.narf.at) Received: from wombat.fafoe.narf.at (wombat.fafoe.narf.at [192.168.1.42]) by fafoe.narf.at (Postfix) with ESMTP id 86E483FA7; Wed, 8 Jun 2005 18:41:41 +0200 (CEST) Received: by wombat.fafoe.narf.at (Postfix, from userid 1001) id D9ECD2DD; Wed, 8 Jun 2005 18:41:38 +0200 (CEST) Date: Wed, 8 Jun 2005 18:41:38 +0200 From: Stefan Farfeleder To: Michael Reifenberger Message-ID: <20050608164134.GC17962@wombat.fafoe.narf.at> Mail-Followup-To: Michael Reifenberger , standards@freebsd.org References: <20050608094851.D29843@fw.reifenberger.com> <20050608103045.GC16848@wombat.fafoe.narf.at> <20050608124306.X30581@fw.reifenberger.com> <20050608125416.GA17962@wombat.fafoe.narf.at> <20050608152614.H31265@fw.reifenberger.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050608152614.H31265@fw.reifenberger.com> User-Agent: Mutt/1.5.9i Cc: standards@freebsd.org Subject: Re: libstand functions not ansi-c compiliant 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, 08 Jun 2005 16:41:49 -0000 On Wed, Jun 08, 2005 at 03:32:09PM +0200, Michael Reifenberger wrote: > On Wed, 8 Jun 2005, Stefan Farfeleder wrote: > > > >On Wed, Jun 08, 2005 at 12:52:42PM +0200, Michael Reifenberger wrote: > >> > >>The advantage would be (thats how I got to this issue at all) that > >>you don't get compiling errors when including too. > >>(I had to do this to get the definition of FILE for the work > >>on upgrading sys/boot/ficl to ficl4) > > > >I'd consider including from sys/boot/ficl a bug. > > > > Maybe. Thats debatable. > But by default ficl.h (coming with ficl4)does inslude > and ficl4 says about itself: ...Ficl is written in strict ANSI C... > Unfortunately is part of ANSI-C... > So one cant blame ficl4 for that. No, but a boot loader is not a hosted implementation. Ficl needs to be patched to use our I/O functions. Stefan From owner-freebsd-standards@FreeBSD.ORG Thu Jun 9 10:12:43 2005 Return-Path: X-Original-To: standards@freebsd.org 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 B947816A41C for ; Thu, 9 Jun 2005 10:12:43 +0000 (GMT) (envelope-from mike@reifenberger.com) Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5028943D1F for ; Thu, 9 Jun 2005 10:12:42 +0000 (GMT) (envelope-from mike@reifenberger.com) Received: from fwd18.aul.t-online.de by mailout03.sul.t-online.com with smtp id 1DgK1h-0004aU-00; Thu, 09 Jun 2005 12:12:41 +0200 Received: from fw.reifenberger.com (Sy-XeuZCQeqX5catG19Klvwbn8rPSkbRA1UJ0zIBH3mllHLAIuQ-U6@[84.152.67.155]) by fwd18.sul.t-online.de with esmtp id 1DgK1b-1tm9jc0; Thu, 9 Jun 2005 12:12:35 +0200 Received: from localhost (mike@localhost) by fw.reifenberger.com (8.13.3/8.13.3/Submit) with ESMTP id j59ACAmW035870; Thu, 9 Jun 2005 12:12:10 +0200 (CEST) (envelope-from mike@reifenberger.com) X-Authentication-Warning: fw.reifenberger.com: mike owned process doing -bs Date: Thu, 9 Jun 2005 12:12:10 +0200 (CEST) From: Michael Reifenberger To: Stefan Farfeleder In-Reply-To: <20050608164134.GC17962@wombat.fafoe.narf.at> Message-ID: <20050609115516.K35479@fw.reifenberger.com> References: <20050608094851.D29843@fw.reifenberger.com> <20050608103045.GC16848@wombat.fafoe.narf.at> <20050608124306.X30581@fw.reifenberger.com> <20050608125416.GA17962@wombat.fafoe.narf.at> <20050608152614.H31265@fw.reifenberger.com> <20050608164134.GC17962@wombat.fafoe.narf.at> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-ID: Sy-XeuZCQeqX5catG19Klvwbn8rPSkbRA1UJ0zIBH3mllHLAIuQ-U6@t-dialin.net X-TOI-MSGID: fd611ccd-af02-4656-9387-ed4b3be7fe48 Cc: standards@freebsd.org Subject: Re: libstand functions not ansi-c compiliant 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, 09 Jun 2005 10:12:43 -0000 On Wed, 8 Jun 2005, Stefan Farfeleder wrote: > Date: Wed, 8 Jun 2005 18:41:38 +0200 > From: Stefan Farfeleder > To: Michael Reifenberger > Cc: standards@freebsd.org > Subject: Re: libstand functions not ansi-c compiliant > >>> I'd consider including from sys/boot/ficl a bug. >>> >> >> Maybe. Thats debatable. >> But by default ficl.h (coming with ficl4)does inslude >> and ficl4 says about itself: ...Ficl is written in strict ANSI C... >> Unfortunately is part of ANSI-C... >> So one cant blame ficl4 for that. > > No, but a boot loader is not a hosted implementation. Ficl needs to be > patched to use our I/O functions. > Ok. Back to the original question: Is there a technical reason that the declaration and implementation of putchar, vprintf and vsprintf in stand.h should NOT conform to ANSI-C respective is there a technical reason these functions MUST return void? Bye/2 --- Michael Reifenberger, Business Development Manager SAP-Basis, Plaut Consulting Comp: Michael.Reifenberger@plaut.de | Priv: Michael@Reifenberger.com http://www.plaut.de | http://www.Reifenberger.com From owner-freebsd-standards@FreeBSD.ORG Fri Jun 10 05:33:07 2005 Return-Path: X-Original-To: freebsd-standards@FreeBSD.ORG 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 04C8C16A41C; Fri, 10 Jun 2005 05:33:07 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from smtp4.server.rpi.edu (smtp4.server.rpi.edu [128.113.2.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4A6843D1F; Fri, 10 Jun 2005 05:33:06 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp4.server.rpi.edu (8.13.0/8.13.0) with ESMTP id j5A5X3j1014927; Fri, 10 Jun 2005 01:33:05 -0400 Mime-Version: 1.0 Message-Id: Date: Fri, 10 Jun 2005 01:33:02 -0400 To: freebsd-arch@FreeBSD.ORG From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.4 Cc: freebsd-standards@FreeBSD.ORG Subject: Change the executing of a 0-byte file to be an error... X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2005 05:33:07 -0000 A few months ago, I had a system panic happen right in the middle of a 'installworld'. Right now I don't care about the panic itself (IIRC, it was a hardware problem), but there was one unexpected side-effect which caused me more trouble than the original panic. And all that trouble boils down to the following: If a file is empty and executable, that empty file can be executed without generating any error. The panic caused a few files in /usr/bin to end up as zero-byte executable files, but I didn't realize that. I ended up doing another buildworld, I think it was, and ended up digging myself into a deeper and deeper hole. The problem included things like makefile rules calling: somecmd | sort -blah | domore where the 'sort' command had turned into one of those zero-byte executable files. The basic result was that the more I tried to rebuild parts of the world, the more screwed up the system became. By the time I was done, I had to do a clean install from CD-ROM to get it back to working order. Can anyone think of a real-world problem that would come up if the system was changed so that executing a 0-byte file would cause an error? I read through a few likely pages in SUSv3, and it looked like the behavior for executing an 0-byte file is not explicitly defined. Of course, it might be that I was simply looking in the wrong part of the standard. It does seem like empty files are also executed without error on a few other OS's I tried, but I don't understand why that behavior would be desirable. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-standards@FreeBSD.ORG Fri Jun 10 06:13:50 2005 Return-Path: X-Original-To: freebsd-standards@freebsd.org 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 A0D0716A41C; Fri, 10 Jun 2005 06:13:50 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (berlin-qwest.village.org [168.103.84.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC8DB43D1F; Fri, 10 Jun 2005 06:13:49 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j5A6CIFI043547; Fri, 10 Jun 2005 00:12:18 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 10 Jun 2005 00:12:18 -0600 (MDT) Message-Id: <20050610.001218.74707358.imp@bsdimp.com> To: drosih@rpi.edu From: Warner Losh In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-standards@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Change the executing of a 0-byte file to be an error... X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2005 06:13:50 -0000 > It does seem like empty files are also executed without error on a > few other OS's I tried, but I don't understand why that behavior > would be desirable. At one point, true was an empty file with the execute bit set. Warner From owner-freebsd-standards@FreeBSD.ORG Fri Jun 10 11:11:05 2005 Return-Path: X-Original-To: freebsd-standards@FreeBSD.ORG 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 6788E16A41C; Fri, 10 Jun 2005 11:11:05 +0000 (GMT) (envelope-from setantae@submonkey.net) Received: from shrike.submonkey.net (cpc4-cdif3-6-1-cust116.cdif.cable.ntl.com [82.23.41.116]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF69943D1F; Fri, 10 Jun 2005 11:11:04 +0000 (GMT) (envelope-from setantae@submonkey.net) Received: from setantae by shrike.submonkey.net with local (Exim 4.51 (FreeBSD)) id 1DghPj-0001zo-Rg; Fri, 10 Jun 2005 12:11:03 +0100 Date: Fri, 10 Jun 2005 12:11:03 +0100 From: Ceri Davies To: Garance A Drosihn Message-ID: <20050610111103.GE14221@submonkey.net> Mail-Followup-To: Ceri Davies , Garance A Drosihn , freebsd-arch@FreeBSD.ORG, freebsd-standards@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YkNwngLRNOQA9swf" Content-Disposition: inline In-Reply-To: X-PGP: finger ceri@FreeBSD.org User-Agent: Mutt/1.5.9i Sender: Ceri Davies Cc: freebsd-standards@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: Change the executing of a 0-byte file to be an error... X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2005 11:11:05 -0000 --YkNwngLRNOQA9swf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 10, 2005 at 01:33:02AM -0400, Garance A Drosihn wrote: > A few months ago, I had a system panic happen right in the middle of > a 'installworld'. Right now I don't care about the panic itself > (IIRC, it was a hardware problem), but there was one unexpected > side-effect which caused me more trouble than the original panic. > And all that trouble boils down to the following: >=20 > If a file is empty and executable, that empty file can be > executed without generating any error. >=20 > The panic caused a few files in /usr/bin to end up as zero-byte > executable files, but I didn't realize that. I ended up doing > another buildworld, I think it was, and ended up digging myself > into a deeper and deeper hole. The problem included things like > makefile rules calling: >=20 > somecmd | sort -blah | domore >=20 > where the 'sort' command had turned into one of those zero-byte > executable files. The basic result was that the more I tried to > rebuild parts of the world, the more screwed up the system became. > By the time I was done, I had to do a clean install from CD-ROM > to get it back to working order. >=20 > Can anyone think of a real-world problem that would come up if the > system was changed so that executing a 0-byte file would cause an > error? I read through a few likely pages in SUSv3, and it looked > like the behavior for executing an 0-byte file is not explicitly > defined. Of course, it might be that I was simply looking in the > wrong part of the standard. >=20 > It does seem like empty files are also executed without error on a > few other OS's I tried, but I don't understand why that behavior > would be desirable. Are you sure? It seems to be a function of the shell more than anything; the transcript below does exactly the same on both FreeBSD 4-STABLE and Solaris 8: $ sh $ PS1=3D'sh$ ' sh$ touch empty ; chmod +x empty sh$ ./empty sh$ echo $? 0 sh$ PS1=3D'zsh$ ' zsh zsh$ zsh zsh$ ./empty zsh: exec format error: ./empty zsh$=20 Ceri --=20 Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. -- Einstein (attrib.) --YkNwngLRNOQA9swf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCqXVHocfcwTS3JF8RAip2AJ9cIIilTOv8Z1rb8pUsTL1MZu3l3QCgkNgy ASHMulCVdnArBtAv05geFOk= =memd -----END PGP SIGNATURE----- --YkNwngLRNOQA9swf-- From owner-freebsd-standards@FreeBSD.ORG Fri Jun 10 11:32:29 2005 Return-Path: X-Original-To: freebsd-standards@freebsd.org 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 3352E16A41C for ; Fri, 10 Jun 2005 11:32:29 +0000 (GMT) (envelope-from wartan.hachaturow@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id D40F143D4C for ; Fri, 10 Jun 2005 11:32:28 +0000 (GMT) (envelope-from wartan.hachaturow@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so340923wra for ; Fri, 10 Jun 2005 04:32:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=b9/3n5XT/tN5khKtsn4KyKn8WzcHyD3RhwhVXS94connl1K5ULm4DXflTDLQvtiAGSG/KTRY/es7Ci/iJzG79/nHiZGQreqdEINB8yZ+94TNiqqimyEF3o/r0+0d8O5HNitSCUmGsvCeBpppRW//0oNNBshPmCZWdPvn8o2fG4w= Received: by 10.54.116.20 with SMTP id o20mr911690wrc; Fri, 10 Jun 2005 04:32:28 -0700 (PDT) Received: by 10.54.102.12 with HTTP; Fri, 10 Jun 2005 04:32:27 -0700 (PDT) Message-ID: <4aaa2e1c0506100432117ea3b8@mail.gmail.com> Date: Fri, 10 Jun 2005 15:32:27 +0400 From: Wartan Hachaturow To: Garance A Drosihn In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: Cc: freebsd-standards@freebsd.org Subject: Re: Change the executing of a 0-byte file to be an error... X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Wartan Hachaturow List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2005 11:32:29 -0000 On 6/10/05, Garance A Drosihn wrote: > error? I read through a few likely pages in SUSv3, and it looked > like the behavior for executing an 0-byte file is not explicitly > defined. Of course, it might be that I was simply looking in the > wrong part of the standard. To quote SUSv3's Shell and Utilities: "If the execve() function fails due to an error equivalent to the [ENOEXEC] error defined in the System Interfaces volume of IEEE Std 1003.1-2001, the shell shall execute a command equivalent to having a shell invoked with the command name as its first operand, with any remaining arguments passed to the new shell. If the executable file is not a text file, the shell may bypass this command execution. In this case, it shall write an error message, and shall return an exit status of 126." So it is merely an empty script execution. The kernel reports a failure, as= it should. --=20 Regards, Wartan. From owner-freebsd-standards@FreeBSD.ORG Fri Jun 10 11:37:28 2005 Return-Path: X-Original-To: freebsd-standards@freebsd.org 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 6553116A41C for ; Fri, 10 Jun 2005 11:37:28 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-1.dlr.de (smtp-1.dlr.de [195.37.61.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0E0943D48 for ; Fri, 10 Jun 2005 11:37:27 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-1.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Jun 2005 13:37:26 +0200 Date: Fri, 10 Jun 2005 13:37:28 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Wartan Hachaturow In-Reply-To: <4aaa2e1c0506100432117ea3b8@mail.gmail.com> Message-ID: <20050610133505.U646@beagle.kn.op.dlr.de> References: <4aaa2e1c0506100432117ea3b8@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 10 Jun 2005 11:37:26.0199 (UTC) FILETIME=[C681BC70:01C56DB0] Cc: freebsd-standards@freebsd.org, Garance A Drosihn Subject: Re: Change the executing of a 0-byte file to be an error... X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2005 11:37:28 -0000 On Fri, 10 Jun 2005, Wartan Hachaturow wrote: WH>On 6/10/05, Garance A Drosihn wrote: WH> WH>> error? I read through a few likely pages in SUSv3, and it looked WH>> like the behavior for executing an 0-byte file is not explicitly WH>> defined. Of course, it might be that I was simply looking in the WH>> wrong part of the standard. WH> WH>To quote SUSv3's Shell and Utilities: WH>"If the execve() function fails due to an error equivalent to the WH>[ENOEXEC] error defined in the System Interfaces volume of IEEE Std WH>1003.1-2001, the shell shall execute a command equivalent to having a WH>shell invoked with the command name as its first operand, with any WH>remaining arguments passed to the new shell. If the executable file is WH>not a text file, the shell may bypass this command execution. In this WH>case, it shall write an error message, and shall return an exit status WH>of 126." WH> WH>So it is merely an empty script execution. The kernel reports a failure, as it WH>should. Well, according to Posix an empty file is not a text file ('A file that contains characters organized in one or more lines.'). The 'may' above allows both behaviours for this case. harti From owner-freebsd-standards@FreeBSD.ORG Fri Jun 10 11:56:24 2005 Return-Path: X-Original-To: freebsd-standards@FreeBSD.ORG 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 54C8816A44B; Fri, 10 Jun 2005 11:56:23 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from smtp4.server.rpi.edu (smtp4.server.rpi.edu [128.113.2.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id E699343D49; Fri, 10 Jun 2005 11:56:22 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp4.server.rpi.edu (8.13.0/8.13.0) with ESMTP id j5ABuKL7010070; Fri, 10 Jun 2005 07:56:21 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20050610111103.GE14221@submonkey.net> References: <20050610111103.GE14221@submonkey.net> Date: Fri, 10 Jun 2005 07:56:19 -0400 To: Ceri Davies From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.4 Cc: freebsd-standards@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: Change the executing of a 0-byte file to be an error... X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2005 11:56:24 -0000 At 12:11 PM +0100 6/10/05, Ceri Davies wrote: >On Fri, Jun 10, 2005, Garance A Drosihn wrote: > > >> If a file is empty and executable, that empty file can be > > executed without generating any error. > >Are you sure? It seems to be a function of the shell more than >anything; the transcript below does exactly the same on both >FreeBSD 4-STABLE and Solaris 8: > >$ sh >$ PS1='sh$ ' >sh$ touch empty ; chmod +x empty >sh$ ./empty >sh$ echo $? >0 >sh$ PS1='zsh$ ' zsh >zsh$ zsh >zsh$ ./empty >zsh: exec format error: ./empty >zsh$ Well, zsh can certainly add whatever processing it likes, but my main interest is what routines like 'exec()' will do with the file. In particular, I'm concerned with what happens when either `make' or `sh' execute some 0-byte file, because those are commands which will be doing the most command-executing in the process of `make buildworld'. I'll admit I did not notice that zsh made that check, as I only checked with `sh', `bash', and (inadvertently) `make'. It might be that the kernel is already doing the right thing, and what I actually need to change is `sh' and `make' instead of something in the kernel. I'm certainly willing to figure out what needs to be changed, but I thought I should first see if there are any reasons that I should not make such a change in the first place. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-standards@FreeBSD.ORG Fri Jun 10 12:00:09 2005 Return-Path: X-Original-To: freebsd-standards@FreeBSD.ORG 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 773B616A41F; Fri, 10 Jun 2005 12:00:09 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-1.dlr.de (smtp-1.dlr.de [195.37.61.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id E732E43D1D; Fri, 10 Jun 2005 12:00:08 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-1.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Jun 2005 14:00:07 +0200 Date: Fri, 10 Jun 2005 14:00:06 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Garance A Drosihn In-Reply-To: Message-ID: <20050610135808.J615@beagle.kn.op.dlr.de> References: <20050610111103.GE14221@submonkey.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 10 Jun 2005 12:00:07.0845 (UTC) FILETIME=[F21C6D50:01C56DB3] Cc: Ceri Davies , freebsd-standards@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: Change the executing of a 0-byte file to be an error... X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2005 12:00:09 -0000 On Fri, 10 Jun 2005, Garance A Drosihn wrote: GAD>At 12:11 PM +0100 6/10/05, Ceri Davies wrote: GAD>> On Fri, Jun 10, 2005, Garance A Drosihn wrote: GAD>> > GAD>> > If a file is empty and executable, that empty file can be GAD>> > executed without generating any error. GAD>> GAD>> Are you sure? It seems to be a function of the shell more than GAD>> anything; the transcript below does exactly the same on both GAD>> FreeBSD 4-STABLE and Solaris 8: GAD>> GAD>> $ sh GAD>> $ PS1='sh$ ' GAD>> sh$ touch empty ; chmod +x empty GAD>> sh$ ./empty GAD>> sh$ echo $? GAD>> 0 GAD>> sh$ PS1='zsh$ ' zsh GAD>> zsh$ zsh GAD>> zsh$ ./empty GAD>> zsh: exec format error: ./empty GAD>> zsh$ GAD> GAD>Well, zsh can certainly add whatever processing it likes, but my main GAD>interest is what routines like 'exec()' will do with the file. In GAD>particular, I'm concerned with what happens when either `make' or `sh' GAD>execute some 0-byte file, because those are commands which will be GAD>doing the most command-executing in the process of `make buildworld'. GAD> GAD>I'll admit I did not notice that zsh made that check, as I only checked GAD>with `sh', `bash', and (inadvertently) `make'. It might be that the GAD>kernel is already doing the right thing, and what I actually need to GAD>change is `sh' and `make' instead of something in the kernel. I'm GAD>certainly willing to figure out what needs to be changed, but I GAD>thought I should first see if there are any reasons that I should not GAD>make such a change in the first place. make either uses a shell to execute a command or it uses execl() (depending whether you're in -j or -B mode and whether the line contains shell metacharacters or builtins), so when execl() does the right thing and the shell too, there is nothing to change in make. harti