From owner-freebsd-standards@FreeBSD.ORG Sun Apr 17 02:53:29 2005 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 49F0916A4CE; Sun, 17 Apr 2005 02:53:29 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id E477743D39; Sun, 17 Apr 2005 02:53:28 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.3/8.13.1) with ESMTP id j3H2rRcs064473; Sat, 16 Apr 2005 22:53:27 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j3H2rRNE064471; Sat, 16 Apr 2005 22:53:27 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Sat, 16 Apr 2005 22:53:27 -0400 From: David Schultz To: Xin LI Message-ID: <20050417025327.GA20089@VARK.MIT.EDU> Mail-Followup-To: Xin LI , lx@knight.6test.edu.cn, freebsd-bugs@FreeBSD.ORG, freebsd-standards@FreeBSD.ORG References: <200504161637.j3GGbchA015884@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504161637.j3GGbchA015884@freefall.freebsd.org> cc: freebsd-standards@FreeBSD.ORG cc: freebsd-bugs@FreeBSD.ORG cc: lx@knight.6test.edu.cn Subject: Re: kern/80008: Unnecessary requirement of sa_len in getnameinfo() 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, 17 Apr 2005 02:53:29 -0000 On Sat, Apr 16, 2005, Xin LI wrote: > Synopsis: Unnecessary requirement of sa_len in getnameinfo() > > State-Changed-From-To: open->analyzed > State-Changed-By: delphij > State-Changed-When: Sat Apr 16 16:33:02 GMT 2005 > State-Changed-Why: > Dear freebsd-standards, > > Would you please review the following patch? I have consulted with POSIX > standard and there is no requirement that there must be a "sa_len" field > in sockaddr. Therefore, I think the check should be either removed, or > be replaced with an assignment. Yeah, sa_len has always been a portability problem. Your proposed change looks fine to me. From owner-freebsd-standards@FreeBSD.ORG Sun Apr 17 03:57:25 2005 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 6F22916A4CF; Sun, 17 Apr 2005 03:57:25 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 403BD43D1D; Sun, 17 Apr 2005 03:57:25 +0000 (GMT) (envelope-from delphij@FreeBSD.org) Received: from freefall.freebsd.org (delphij@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j3H3vPP3091300; Sun, 17 Apr 2005 03:57:25 GMT (envelope-from delphij@freefall.freebsd.org) Received: (from delphij@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j3H3vPWO091296; Sun, 17 Apr 2005 03:57:25 GMT (envelope-from delphij) Date: Sun, 17 Apr 2005 03:57:25 GMT From: Xin LI Message-Id: <200504170357.j3H3vPWO091296@freefall.freebsd.org> To: lx@knight.6test.edu.cn, delphij@FreeBSD.org, freebsd-standards@FreeBSD.org, delphij@FreeBSD.org Subject: Re: standards/80008: Unnecessary requirement of sa_len in getnameinfo() 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, 17 Apr 2005 03:57:25 -0000 Synopsis: Unnecessary requirement of sa_len in getnameinfo() State-Changed-From-To: analyzed->patched State-Changed-By: delphij State-Changed-When: Sun Apr 17 03:56:31 GMT 2005 State-Changed-Why: A patch has been committed to -HEAD, MFC reminder. Responsible-Changed-From-To: freebsd-standards->delphij Responsible-Changed-By: delphij Responsible-Changed-When: Sun Apr 17 03:56:31 GMT 2005 Responsible-Changed-Why: Over to me since I have committed the patch. http://www.freebsd.org/cgi/query-pr.cgi?pr=80008 From owner-freebsd-standards@FreeBSD.ORG Mon Apr 18 11:02:16 2005 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 A28FB16A4F5 for ; Mon, 18 Apr 2005 11:02:16 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79FB843D31 for ; Mon, 18 Apr 2005 11:02:16 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j3IB2GcI093426 for ; Mon, 18 Apr 2005 11:02:16 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j3IB2Ewg093420 for freebsd-standards@freebsd.org; Mon, 18 Apr 2005 11:02:14 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 18 Apr 2005 11:02:14 GMT Message-Id: <200504181102.j3IB2Ewg093420@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, 18 Apr 2005 11:02:16 -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/06/18] kern/53447 standards poll(2) semantics differ from susV3/POSIX 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 o [2005/03/09] standards/78650standards ttyname_r() is not standards compliant o [2005/03/16] standards/78907standards does not define pthread typ 12 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 30 problems total. From owner-freebsd-standards@FreeBSD.ORG Tue Apr 19 04:10:26 2005 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 07CE016A4CE for ; Tue, 19 Apr 2005 04:10:26 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD93F43D4C for ; Tue, 19 Apr 2005 04:10:25 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j3J4APEY037095 for ; Tue, 19 Apr 2005 04:10:25 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j3J4APhr037094; Tue, 19 Apr 2005 04:10:25 GMT (envelope-from gnats) Date: Tue, 19 Apr 2005 04:10:25 GMT Message-Id: <200504190410.j3J4APhr037094@freefall.freebsd.org> To: freebsd-standards@FreeBSD.org From: David Schultz Subject: Re: kern/64875: Add a system call: fdatasync() X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: David Schultz List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 04:10:26 -0000 The following reply was made to PR kern/64875; it has been noted by GNATS. From: David Schultz To: Kevin Lo Cc: freebsd-gnats-submit@FreeBSD.ORG, alc@FreeBSD.ORG Subject: Re: kern/64875: Add a system call: fdatasync() Date: Tue, 19 Apr 2005 00:07:48 -0400 On Sun, Mar 28, 2004, Kevin Lo wrote: > >Number: 64875 > >Category: kern > >Synopsis: Add a system call: fdatasync() [...] > >Description: > fdatasync()is part of realtime extensions in POSIX 1003.1. > > DESCRIPTION > The fdatasync() function forces all currently queued I/O > operations associated with the file indicated by file > descriptor fildes to the synchronized I/O completion state. [...] > +int > +fdatasync(td, uap) > + struct thread *td; > + struct fsync_args /* { > + int fd; > + } */ *uap; > +{ > + struct vnode *vp; > + struct file *fp; > + vm_object_t obj; > + int error; > + > + GIANT_REQUIRED; > + > + if ((error = getvnode(td->td_proc->p_fd, uap->fd, &fp)) != 0) > + return (error); > + if ((fp->f_flag & FWRITE) == 0) { > + fdrop(fp, td); > + return (EBADF); > + } > + vp = fp->f_vnode; > + vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, td); > + if (VOP_GETVOBJECT(vp, &obj) == 0) { > + VM_OBJECT_LOCK(obj); > + vm_object_page_clean(obj, 0, 0, 0); > + VM_OBJECT_UNLOCK(obj); > + } > + error = VOP_FSYNC(vp, fp->f_cred, MNT_WAIT, td); > + VOP_UNLOCK(vp, 0, td); > + fdrop(fp, td); > + return (error); > +} This is a good start, but there are several problems with the patch. - The above is basically the same as fsync(). The whole point of fdatasync() is to be more efficient than fsync() by not syncing the file metadata, so it's misleading to implement it as an alias for fsync(). I think a correct implementation could be achieved by omitting the VOP_FSYNC() call and passing the OBJPC_SYNC flag to vm_object_page_clean(), but Alan should review this. - Regarding the above, what's supposed to happen if the file size changes, or if the file was recently created, and its inode has not been written at all yet? I'm not sure whether fdatasync() is supposed to omit all metadata updates or just `unimportant' ones like atime and mtime. If my suggestion above isn't adequate, the VOP_FSYNC() interface may need to be extended. - The proposed documentation for fdatasync() needs to be rewritten, for two reasons. First, although we do have permission to copy text from POSIX, it's still plagiarism to do so without acknowledgement. Second, the POSIX documentation is not very helpful in this case; what's the ``synchronized I/O completion state'' anyway? From owner-freebsd-standards@FreeBSD.ORG Wed Apr 20 12:41:18 2005 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 4418516A4CE for ; Wed, 20 Apr 2005 12:41:18 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id E943343D4C for ; Wed, 20 Apr 2005 12:41:17 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by rproxy.gmail.com with SMTP id i8so122925rne for ; Wed, 20 Apr 2005 05:41:17 -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:mime-version:content-type:content-transfer-encoding:content-disposition; b=QIa0fthIPibEvHKFqw7yZ5/4aQWHrlNhEgB3cT0mf/Y8+1lP1jBj+oxIHOohpAQ2t54QZmXXCsnmt4lboYU4h+ItTyNF0UUJxyuZhOPFr3NAp0cA2jYJ1KOQU+3G+tmeB7QaEwo1p5Hn3Af3MVaFJ3ZxBiIP0sbdcLUlMdZ71Io= Received: by 10.38.150.41 with SMTP id x41mr825427rnd; Wed, 20 Apr 2005 05:41:17 -0700 (PDT) Received: by 10.38.209.22 with HTTP; Wed, 20 Apr 2005 05:41:17 -0700 (PDT) Message-ID: <84dead720504200541539f4c15@mail.gmail.com> Date: Wed, 20 Apr 2005 12:41:17 +0000 From: Joseph Koshy To: freebsd-standards@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Standard type for code pointers? X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Joseph Koshy List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 12:41:18 -0000 I'm looking for a standard type that is defined to have at least=20 as many bits as needed to hold a pointer to code. What would=20 that be? --=20 FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-standards@FreeBSD.ORG Wed Apr 20 13:12:25 2005 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 4F24216A4CF for ; Wed, 20 Apr 2005 13:12:25 +0000 (GMT) Received: from bremen.shuttle.de (bremen.shuttle.de [194.95.249.251]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0418E43D45 for ; Wed, 20 Apr 2005 13:12:24 +0000 (GMT) (envelope-from schweikh@schweikhardt.net) Received: by bremen.shuttle.de (Postfix, from userid 10) id 1E4923B977; Wed, 20 Apr 2005 15:12:21 +0200 (CEST) Received: from hal9000.schweikhardt.net (localhost [127.0.0.1]) j3KECAMF051276; Wed, 20 Apr 2005 16:12:10 +0200 (CEST) (envelope-from schweikh@hal9000.schweikhardt.net) Received: (from schweikh@localhost) by hal9000.schweikhardt.net (8.13.3/8.13.3/Submit) id j3KECAc1051275; Wed, 20 Apr 2005 16:12:10 +0200 (CEST) (envelope-from schweikh) Date: Wed, 20 Apr 2005 16:12:10 +0200 From: Jens Schweikhardt To: Joseph Koshy Message-ID: <20050420141210.GA1271@schweikhardt.net> References: <84dead720504200541539f4c15@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84dead720504200541539f4c15@mail.gmail.com> User-Agent: Mutt/1.5.9i cc: freebsd-standards@freebsd.org Subject: Re: Standard type for code pointers? 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: Wed, 20 Apr 2005 13:12:25 -0000 On Wed, Apr 20, 2005 at 12:41:17PM +0000, Joseph Koshy wrote: # I'm looking for a standard type that is defined to have at least # as many bits as needed to hold a pointer to code. What would # that be? Any function pointer. All pointers to functions are assignment-compatible, but when dereferenced must call a function of the declared type, otherwise the behavior is undefined. Regards, Jens -- Jens Schweikhardt http://www.schweikhardt.net/ SIGSIG -- signature too long (core dumped) From owner-freebsd-standards@FreeBSD.ORG Wed Apr 20 15:34:19 2005 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 85F0216A4CE for ; Wed, 20 Apr 2005 15:34:19 +0000 (GMT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1022443D46 for ; Wed, 20 Apr 2005 15:34:19 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.250] (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.13.3/8.13.3) with ESMTP id j3KFYIQc027915; Wed, 20 Apr 2005 08:34:18 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <84dead720504200541539f4c15@mail.gmail.com> References: <84dead720504200541539f4c15@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <03f22a3c76ac440b97e2179761dfd6fa@xcllnt.net> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Wed, 20 Apr 2005 08:34:18 -0700 To: Joseph Koshy X-Mailer: Apple Mail (2.622) cc: freebsd-standards@freebsd.org Subject: Re: Standard type for code pointers? 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: Wed, 20 Apr 2005 15:34:19 -0000 On Apr 20, 2005, at 5:41 AM, Joseph Koshy wrote: > I'm looking for a standard type that is defined to have at least > as many bits as needed to hold a pointer to code. What would > that be? intptr_t is probably what you want. FYI, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-standards@FreeBSD.ORG Wed Apr 20 15:54:11 2005 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 3BD7F16A4CE for ; Wed, 20 Apr 2005 15:54:11 +0000 (GMT) Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3198443D49 for ; Wed, 20 Apr 2005 15:54:10 +0000 (GMT) (envelope-from ertr1013@student.uu.se) Received: from falcon.midgard.homeip.net (212.181.162.201) by pne-smtpout2-sn2.hy.skanova.net (7.1.026.7) id 42662CF10001765B for freebsd-standards@freebsd.org; Wed, 20 Apr 2005 17:54:09 +0200 Received: (qmail 891 invoked by uid 1001); 20 Apr 2005 15:54:08 -0000 Date: Wed, 20 Apr 2005 17:54:08 +0200 From: Erik Trulsson To: Marcel Moolenaar Message-ID: <20050420155407.GA844@falcon.midgard.homeip.net> Mail-Followup-To: Marcel Moolenaar , Joseph Koshy , freebsd-standards@freebsd.org References: <84dead720504200541539f4c15@mail.gmail.com> <03f22a3c76ac440b97e2179761dfd6fa@xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03f22a3c76ac440b97e2179761dfd6fa@xcllnt.net> User-Agent: Mutt/1.5.9i cc: freebsd-standards@freebsd.org Subject: Re: Standard type for code pointers? 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: Wed, 20 Apr 2005 15:54:11 -0000 On Wed, Apr 20, 2005 at 08:34:18AM -0700, Marcel Moolenaar wrote: > > On Apr 20, 2005, at 5:41 AM, Joseph Koshy wrote: > > >I'm looking for a standard type that is defined to have at least > >as many bits as needed to hold a pointer to code. What would > >that be? > > intptr_t is probably what you want. Except that intptr_t need only be large enough to hold an object pointer. This is not necessarily enough to hold a function pointer. The only standard types that are guaranteed to be able to hold a function pointer are other function pointers. -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-standards@FreeBSD.ORG Wed Apr 20 16:10:31 2005 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 D763F16A4CE for ; Wed, 20 Apr 2005 16:10:31 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78DAA43D46 for ; Wed, 20 Apr 2005 16:10:31 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by rproxy.gmail.com with SMTP id z35so187585rne for ; Wed, 20 Apr 2005 09:10:31 -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:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gJYXtqUCIkjBRW1HjCE6WzuFEect8Qrk9C4P0IzgyRPXlnrPq2iAUomQI97+nX2q10h2B3lma9cPlsYB/jRwMOvT/pxSHLpmze610UW2OQ7qXrnpvOpDdtucNhroEN7cnJsKaarM5TWc7zsBeH5xs2MGQdWQxWZF2fzkkOxw5sk= Received: by 10.38.75.59 with SMTP id x59mr1057742rna; Wed, 20 Apr 2005 09:10:30 -0700 (PDT) Received: by 10.38.209.22 with HTTP; Wed, 20 Apr 2005 09:10:30 -0700 (PDT) Message-ID: <84dead720504200910441b9108@mail.gmail.com> Date: Wed, 20 Apr 2005 16:10:30 +0000 From: Joseph Koshy To: Marcel Moolenaar , freebsd-standards@freebsd.org In-Reply-To: <20050420155407.GA844@falcon.midgard.homeip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <84dead720504200541539f4c15@mail.gmail.com> <03f22a3c76ac440b97e2179761dfd6fa@xcllnt.net> <20050420155407.GA844@falcon.midgard.homeip.net> Subject: Re: Standard type for code pointers? X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Joseph Koshy List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 16:10:31 -0000 > Except that intptr_t need only be large enough to hold an=20 > object pointer. This is not necessarily enough to hold a=20 > function pointer. Right. > The only standard types that are guaranteed to be able to hold > a function pointer are other function pointers. Right, but there doesn't seem to be a C99 name for function pointer types. Is 'register_t' guaranteed to be wide enough? --=20 FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-standards@FreeBSD.ORG Wed Apr 20 16:23:53 2005 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 0E85716A4CE for ; Wed, 20 Apr 2005 16:23:53 +0000 (GMT) Received: from kane.otenet.gr (kane.otenet.gr [195.170.0.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB69F43D4C for ; Wed, 20 Apr 2005 16:23:45 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from orion.daedalusnetworks.priv (aris.bedc.ondsl.gr [62.103.39.226])j3KGMSXg008885; Wed, 20 Apr 2005 19:22:32 +0300 Received: from orion.daedalusnetworks.priv (orion [127.0.0.1]) j3KGNX7f053034; Wed, 20 Apr 2005 19:23:33 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost)j3KGNW1t053033; Wed, 20 Apr 2005 19:23:32 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Wed, 20 Apr 2005 19:23:32 +0300 From: Giorgos Keramidas To: Joseph Koshy Message-ID: <20050420162332.GB52948@orion.daedalusnetworks.priv> References: <84dead720504200541539f4c15@mail.gmail.com> <03f22a3c76ac440b97e2179761dfd6fa@xcllnt.net> <20050420155407.GA844@falcon.midgard.homeip.net> <84dead720504200910441b9108@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84dead720504200910441b9108@mail.gmail.com> cc: freebsd-standards@freebsd.org Subject: Re: Standard type for code pointers? 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: Wed, 20 Apr 2005 16:23:53 -0000 On 2005-04-20 16:10, Joseph Koshy wrote: >> Except that intptr_t need only be large enough to hold an object >> pointer. This is not necessarily enough to hold a function pointer. > > Right. > >> The only standard types that are guaranteed to be able to hold a >> function pointer are other function pointers. > > Right, but there doesn't seem to be a C99 name for function > pointer types. There is no need for an explicit typedef. If you do know the type of the function pointed at by a function pointer, you can declare the pointer using the correct type: char prog_name[] = "/bin/sh"; char *args[] = { prog_name }; int (*fptr)(int, char **); fptr = main; fptr(1, args); > Is 'register_t' guaranteed to be wide enough? AFAIK, no. Portable C code cannot assume that a function pointer is small enough to fit in a single machine register. Some obscure architecture may choose to represent function entry points with as many register as it needs. From owner-freebsd-standards@FreeBSD.ORG Wed Apr 20 16:36:29 2005 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 DF48F16A4CE for ; Wed, 20 Apr 2005 16:36:29 +0000 (GMT) Received: from pne-smtpout2-sn1.fre.skanova.net (pne-smtpout2-sn1.fre.skanova.net [81.228.11.159]) by mx1.FreeBSD.org (Postfix) with ESMTP id D350243D1F for ; Wed, 20 Apr 2005 16:36:28 +0000 (GMT) (envelope-from ertr1013@student.uu.se) Received: from falcon.midgard.homeip.net (212.181.162.201) by pne-smtpout2-sn1.fre.skanova.net (7.1.026.7) id 41E3209600D72003 for freebsd-standards@freebsd.org; Wed, 20 Apr 2005 18:36:28 +0200 Received: (qmail 1458 invoked by uid 1001); 20 Apr 2005 16:36:27 -0000 Date: Wed, 20 Apr 2005 18:36:27 +0200 From: Erik Trulsson To: Joseph Koshy Message-ID: <20050420163627.GA1316@falcon.midgard.homeip.net> Mail-Followup-To: Joseph Koshy , Marcel Moolenaar , freebsd-standards@freebsd.org References: <84dead720504200541539f4c15@mail.gmail.com> <03f22a3c76ac440b97e2179761dfd6fa@xcllnt.net> <20050420155407.GA844@falcon.midgard.homeip.net> <84dead720504200910441b9108@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84dead720504200910441b9108@mail.gmail.com> User-Agent: Mutt/1.5.9i cc: freebsd-standards@freebsd.org Subject: Re: Standard type for code pointers? 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: Wed, 20 Apr 2005 16:36:30 -0000 On Wed, Apr 20, 2005 at 04:10:30PM +0000, Joseph Koshy wrote: > > Except that intptr_t need only be large enough to hold an > > object pointer. This is not necessarily enough to hold a > > function pointer. > > Right. > > > The only standard types that are guaranteed to be able to hold > > a function pointer are other function pointers. > > Right, but there doesn't seem to be a C99 name for function > pointer types. No, but since any function pointer type is large enough to hold any function pointer you can just pick one. (But when you actually call a function pointer, it must be a pointer of the correct type.) > > Is 'register_t' guaranteed to be wide enough? No idea. It is not part of the C standard anyway. -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-standards@FreeBSD.ORG Wed Apr 20 17:39:00 2005 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 7B3BA16A4CE for ; Wed, 20 Apr 2005 17:39:00 +0000 (GMT) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2052D43D39 for ; Wed, 20 Apr 2005 17:39:00 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id 440C31F096; Wed, 20 Apr 2005 19:38:59 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id 26A776583; Wed, 20 Apr 2005 19:38:59 +0200 (CEST) Date: Wed, 20 Apr 2005 19:38:59 +0200 From: Marc Olzheim To: freebsd-standards@freebsd.org Message-ID: <20050420173859.GA99695@stack.nl> References: <20050419133227.GA11612@stack.nl> <20050419151800.GE1157@green.homeunix.org> <20050419160258.GA12287@stack.nl> <20050419160900.GB12287@stack.nl> <20050419161616.GF1157@green.homeunix.org> <20050419204723.GG1157@green.homeunix.org> <20050420140409.GA77731@stack.nl> <20050420142448.GH1157@green.homeunix.org> <20050420143842.GB77731@stack.nl> <16998.36437.809896.936800@khavrinen.csail.mit.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ibTvN161/egqYuK8" Content-Disposition: inline In-Reply-To: <16998.36437.809896.936800@khavrinen.csail.mit.edu> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i cc: Marc Olzheim cc: Garrett Wollman Subject: Re: NFS client/buffer cache deadlock 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: Wed, 20 Apr 2005 17:39:00 -0000 --ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 20, 2005 at 01:16:05PM -0400, Garrett Wollman wrote: > < sai= d: >=20 > > Btw.: I'm not sure write(),writev() and pwrite() are allowed to do short > > writes on regular files... ? >=20 > I believe it is the intent of the Standard to prohibit this (a > paragraph in the rationale says that short writes can only happen if > O_NONBLOCK is set, but this is clearly wrong because the normative > text says end-of-medium also results in a short write) but there does > not appear to be any language which requires atomic behavior for > descriptors other than pipes and FIFOs. >=20 > As a quality-of-implementation matter, for writes to regular files not > to be atomic would be considered surprising. >=20 > -GAWollman Could someone from standards comment here ? I believe Garrett is right... (thread is on -hackers and -current) Marc --ibTvN161/egqYuK8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCZpOzezjnobFOgrERAnLDAJ9Vaq4bpJkVoUOC/npsG07DllHd2gCgwDmn 8mEJcwidDAFtEadBZvuiPWQ= =sN7A -----END PGP SIGNATURE----- --ibTvN161/egqYuK8-- From owner-freebsd-standards@FreeBSD.ORG Thu Apr 21 04:56:16 2005 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 C426B16A4CE for ; Thu, 21 Apr 2005 04:56:16 +0000 (GMT) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id F29EA43D45 for ; Thu, 21 Apr 2005 04:56:15 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])j3L4uAml002046; Thu, 21 Apr 2005 14:56:10 +1000 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) j3L4u50I025325; Thu, 21 Apr 2005 14:56:07 +1000 Date: Thu, 21 Apr 2005 14:56:05 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Marc Olzheim In-Reply-To: <20050420173859.GA99695@stack.nl> Message-ID: <20050421135507.D88964@delplex.bde.org> References: <20050419133227.GA11612@stack.nl> <20050419151800.GE1157@green.homeunix.org> <20050419160258.GA12287@stack.nl> <20050419160900.GB12287@stack.nl> <20050419204723.GG1157@green.homeunix.org> <20050420142448.GH1157@green.homeunix.org> <16998.36437.809896.936800@khavrinen.csail.mit.edu> <20050420173859.GA99695@stack.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: Garrett Wollman cc: freebsd-standards@FreeBSD.org Subject: Re: NFS client/buffer cache deadlock 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: Thu, 21 Apr 2005 04:56:16 -0000 On Wed, 20 Apr 2005, Marc Olzheim wrote: > On Wed, Apr 20, 2005 at 01:16:05PM -0400, Garrett Wollman wrote: >> < said: >> >>> Btw.: I'm not sure write(),writev() and pwrite() are allowed to do short >>> writes on regular files... ? >> >> I believe it is the intent of the Standard to prohibit this (a >> paragraph in the rationale says that short writes can only happen if >> O_NONBLOCK is set, but this is clearly wrong because the normative >> text says end-of-medium also results in a short write) but there does >> not appear to be any language which requires atomic behavior for >> descriptors other than pipes and FIFOs. >> >> As a quality-of-implementation matter, for writes to regular files not >> to be atomic would be considered surprising. >> >> -GAWollman > > Could someone from standards comment here ? I believe Garrett is > right... > (thread is on -hackers and -current) I can't see anywhere that POSIX actually requires this. ffs only backs out short writes in some (most) cases. I have the following notes about this: % Index: ffs_vnops.c % =================================================================== % RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_vnops.c,v % retrieving revision 1.130 % diff -u -2 -r1.130 ffs_vnops.c % --- ffs_vnops.c 21 May 2004 12:05:48 -0000 1.130 % +++ ffs_vnops.c 29 May 2004 13:16:07 -0000 % @@ -719,4 +730,8 @@ % * we clear the setuid and setgid bits as a precaution against % * tampering. % + * XXX too late, the tamperer may have opened the file while we % + * were writing the data (or before). This comment is probably wrong, since locking should prevent concurrent access. % + * XXX too early, if (error && ioflag & IO_UNIT) then we will % + * unwrite the data. (1) % */ % if (resid > uio->uio_resid && ap->a_cred && % @@ -725,7 +740,12 @@ % DIP(ip, i_mode) = ip->i_mode; % } % + /* XXX this seems to be misplaced. Which resid? */ % if (resid > uio->uio_resid) % VN_KNOTE(vp, NOTE_WRITE | (extended ? NOTE_EXTEND : 0)); % if (error) { % + /* % + * XXX should truncate to the last successfully written % + * data if the uiomove() failed. % + */ (2) % if (ioflag & IO_UNIT) { % (void)UFS_TRUNCATE(vp, osize, In FreeBSD-1, I fixed the bug mentioned in comments (1) and (2) by backing out short writes in the error == EFAULT case as well as in the IO_UNIT case (most writes are with IO_UNIT so short ones get backed out without this). Now I think that IO_UNIT shouldn't exist and all writes to regular files should be as atomic as possible, and in particular, short writes should always be backed out in the above. IO_UNIT is set in almost all cases. It is set in vn_write(), so it is normally set for regular files. It is set for all (?) writes generated by the kernel itself. E.g., it is set for core dumps, although that use is bogus since core dumps aren't atomic and even the atomicness that they once had has rotted (*). I thought that IO_UNIT was used in all important cases, but I recently noticed that nfs doesn't seem to use it. Perhaps that is the bug that initiated this thread. Individual file systems barely use IO_UNIT. ffs's only use of it is to give low quality behaviour in the above. Handling of short writes (and reads) is broken for non-regular files too. One of my notes about this is: % Index: sys_generic.c % =================================================================== % RCS file: /home/ncvs/src/sys/kern/sys_generic.c,v % retrieving revision 1.131 % diff -u -2 -r1.131 sys_generic.c % --- sys_generic.c 5 Apr 2004 21:03:35 -0000 1.131 % +++ sys_generic.c 6 Apr 2004 10:17:12 -0000 % @@ -420,4 +415,5 @@ % bwillwrite(); % if ((error = fo_write(fp, &auio, td->td_ucred, flags, td))) { % + /* XXX short write botch - should && be ||? */ % if (auio.uio_resid != cnt && (error == ERESTART || % error == EINTR || error == EWOULDBLOCK)) The condition for a short write is (auio.uio_resid != cnt). When there is a short write, the amount that was written must be returned. This requires ignoring `error', but `error' is only ignored if it is ERESTART, EINTR or EWOULDBLOCK. One case that is broken is writing to a tty that gets hung up after writing something. Then a short (non-null) write with error = EIO is returned. This case is unimportant, since writing the data at the level of tty.c is no guarantee that it has gone further than the driver's buffers (possibly several layers of these), let alone that it has been seen by its intended recipient. Short writes for tape drives are probably the most important. This bug would be more obvious if it happened for regular files. Then callers can easily see that the file was extended despite write() bogusly returning -1. In fact, my simple test for this failure (written in 1996) still acts strangely for nfs under my 1 year old version of -current: %%% #include #include #include #define SIZE 0x10000 main() { void *buf; int n; buf = malloc(0x10000); n = write(1, buf, 0x20000); perror(""); fprintf(stderr, "write %d\n", n); fprintf(stderr, "offset %qd\n", lseek(1, 0ll, SEEK_CUR)); } %%% This doesn't show any bugs directly. write() returns -1 and the offset is correct (65536). However, ls shows a file size of 73728 (8192 too long), and trying to read the extra bytes returns 0 and magically fixes up the file size to 65536. (*) On non-atomicity of core dumps: In FreeBSD-1, the vnode was locked throughout a core dump, so writing cores was atomic even if there are several sections, but if one of the writes failed then the previous successful ones were not backed out so the core is garbage after an error, and there is no indication of the error to userland. Now the vnode is intentionally left unlocked and even natural large blocks (sections for ELF) are intentionally written non-atomically using vn_rdwr_inchunks(), so that that the whole file system doesn't tend to hang while writing cores. Error handling after a write failure is no better, and applications can see cores that are garbage because thet are incomplete. Bruce From owner-freebsd-standards@FreeBSD.ORG Thu Apr 21 05:42:55 2005 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 1BC2316A4CE for ; Thu, 21 Apr 2005 05:42:55 +0000 (GMT) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8275943D39 for ; Thu, 21 Apr 2005 05:42:54 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])j3L5grJu031023; Thu, 21 Apr 2005 15:42:53 +1000 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) j3L5gm0I010875; Thu, 21 Apr 2005 15:42:50 +1000 Date: Thu, 21 Apr 2005 15:42:48 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Erik Trulsson In-Reply-To: <20050420155407.GA844@falcon.midgard.homeip.net> Message-ID: <20050421153551.Q89192@delplex.bde.org> References: <84dead720504200541539f4c15@mail.gmail.com> <20050420155407.GA844@falcon.midgard.homeip.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-standards@FreeBSD.org Subject: Re: Standard type for code pointers? 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: Thu, 21 Apr 2005 05:42:55 -0000 On Wed, 20 Apr 2005, Erik Trulsson wrote: > On Wed, Apr 20, 2005 at 08:34:18AM -0700, Marcel Moolenaar wrote: >> >> On Apr 20, 2005, at 5:41 AM, Joseph Koshy wrote: >> >>> I'm looking for a standard type that is defined to have at least >>> as many bits as needed to hold a pointer to code. What would >>> that be? >> >> intptr_t is probably what you want. > > Except that intptr_t need only be large enough to hold an object > pointer. This is not necessarily enough to hold a function pointer. > > The only standard types that are guaranteed to be able to hold a > function pointer are other function pointers. There is no standard type for this, but there FreeBSD has the following: uintfptr_t: like uintptr_t except for function types fptrdiff_t: like ptrdiff_t except for function types These are defined in and are supposed to be used in all profiling code written in C in the last 10 years (gprof is much older and doesn't use them except via their use in ; gprof converts almost everything to floating point anyway, and is probably horribly broken if the function address space isn't flat (but a non-flat space could be flattened for it)). Bruce From owner-freebsd-standards@FreeBSD.ORG Fri Apr 22 15:30:41 2005 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 5FD1716A4CE for ; Fri, 22 Apr 2005 15:30:41 +0000 (GMT) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id C326D43D41 for ; Fri, 22 Apr 2005 15:30:40 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id C951C1F061 for ; Fri, 22 Apr 2005 17:30:39 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id A352E6563; Fri, 22 Apr 2005 17:30:39 +0200 (CEST) Date: Fri, 22 Apr 2005 17:30:39 +0200 From: Marc Olzheim To: freebsd-standards@freebsd.org Message-ID: <20050422153039.GA18154@stack.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i Subject: Shell -e behaviour 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: Fri, 22 Apr 2005 15:30:41 -0000 --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi. I know that it's no sinecure to change the behaviour of /bin/sh bacause of the impact on all kinds of scripts written for it and that's probably why there are so many differences between shell implemetations floating around. I gathered some info about some of the differences on http://www.stack.nl/~marcolz/sh-e.html and wondered what way FreeBSD's /bin/sh was going in FreeBSD 6.x/7.x in this specific department... Any comments on how the POSIX standard should be interpreted ? Marc --FCuugMFkClbJLl1L Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCaRifezjnobFOgrERAsyDAKCQRho3t46NtMvTnzYWZPyxU41adACfffwK HdPuCnMz+rhhfA6KAWJ0tss= =Ieg/ -----END PGP SIGNATURE----- --FCuugMFkClbJLl1L--