From owner-freebsd-standards@FreeBSD.ORG Sun Feb 29 02:48:50 2004 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B43F16A4CE; Sun, 29 Feb 2004 02:48:50 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BEEC43D2F; Sun, 29 Feb 2004 02:48:50 -0800 (PST) (envelope-from phk@FreeBSD.org) Received: from freefall.freebsd.org (phk@localhost [127.0.0.1]) i1TAmnbv060374; Sun, 29 Feb 2004 02:48:49 -0800 (PST) (envelope-from phk@freefall.freebsd.org) Received: (from phk@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i1TAmnCt060370; Sun, 29 Feb 2004 02:48:49 -0800 (PST) (envelope-from phk) Date: Sun, 29 Feb 2004 02:48:49 -0800 (PST) From: Poul-Henning Kamp Message-Id: <200402291048.i1TAmnCt060370@freefall.freebsd.org> To: stefan@fafoe.narf.at, phk@FreeBSD.org, freebsd-standards@FreeBSD.org Subject: Re: standards/62858: malloc(0) not C99 compliant 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, 29 Feb 2004 10:48:50 -0000 Synopsis: malloc(0) not C99 compliant State-Changed-From-To: open->suspended State-Changed-By: phk State-Changed-When: Sun Feb 29 02:46:49 PST 2004 State-Changed-Why: This is a deliberate choice. Handling zero-size pointers correctly in malloc(3) would be a rather involved and is currently not high on the todolist. A good patch might change that. http://www.freebsd.org/cgi/query-pr.cgi?pr=62858 From owner-freebsd-standards@FreeBSD.ORG Sun Feb 29 12:45:54 2004 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2628116A4CE; Sun, 29 Feb 2004 12:45:54 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07C1643D2D; Sun, 29 Feb 2004 12:45:54 -0800 (PST) (envelope-from mikeh@FreeBSD.org) Received: from freefall.freebsd.org (mikeh@localhost [127.0.0.1]) i1TKjrbv022434; Sun, 29 Feb 2004 12:45:53 -0800 (PST) (envelope-from mikeh@freefall.freebsd.org) Received: (from mikeh@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i1TKjpkO022430; Sun, 29 Feb 2004 12:45:51 -0800 (PST) (envelope-from mikeh) Date: Sun, 29 Feb 2004 12:45:51 -0800 (PST) From: Mike Heffner Message-Id: <200402292045.i1TKjpkO022430@freefall.freebsd.org> To: wart@tepkom.ru, mikeh@FreeBSD.org, freebsd-standards@FreeBSD.org Subject: Re: standards/61934: [PATCH] FreeBSD's mailx not completely SUSv3-compliant 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, 29 Feb 2004 20:45:54 -0000 Synopsis: [PATCH] FreeBSD's mailx not completely SUSv3-compliant State-Changed-From-To: open->closed State-Changed-By: mikeh State-Changed-When: Sun Feb 29 12:45:31 PST 2004 State-Changed-Why: Committed, thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=61934 From owner-freebsd-standards@FreeBSD.ORG Mon Mar 1 04:24:15 2004 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6159416A4CE; Mon, 1 Mar 2004 04:24:15 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FCD443D2F; Mon, 1 Mar 2004 04:24:15 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 2DCD95308; Mon, 1 Mar 2004 13:24:14 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 072AF530C; Mon, 1 Mar 2004 13:24:08 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id E59F633C6B; Mon, 1 Mar 2004 13:24:07 +0100 (CET) To: Poul-Henning Kamp References: <200402291048.i1TAmnCt060370@freefall.freebsd.org> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Mon, 01 Mar 2004 13:24:07 +0100 In-Reply-To: <200402291048.i1TAmnCt060370@freefall.freebsd.org> (Poul-Henning Kamp's message of "Sun, 29 Feb 2004 02:48:49 -0800 (PST)") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: stefan@fafoe.narf.at cc: freebsd-standards@FreeBSD.org Subject: Re: standards/62858: malloc(0) not C99 compliant 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, 01 Mar 2004 12:24:15 -0000 Poul-Henning Kamp writes: > This is a deliberate choice. Handling zero-size pointers correctly > in malloc(3) would be a rather involved and is currently not high > on the todolist. A good patch might change that. The standard does allow returning NULL, you know. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-standards@FreeBSD.ORG Mon Mar 1 04:28:08 2004 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C80916A4CE for ; Mon, 1 Mar 2004 04:28:08 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B75343D2D for ; Mon, 1 Mar 2004 04:28:07 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i21CRt6l054808; Mon, 1 Mar 2004 13:28:00 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 01 Mar 2004 13:24:07 +0100." Date: Mon, 01 Mar 2004 13:27:55 +0100 Message-ID: <54807.1078144075@critter.freebsd.dk> cc: stefan@fafoe.narf.at cc: freebsd-standards@FreeBSD.org Subject: Re: standards/62858: malloc(0) not C99 compliant 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, 01 Mar 2004 12:28:08 -0000 In message , Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= writes: >Poul-Henning Kamp writes: >> This is a deliberate choice. Handling zero-size pointers correctly >> in malloc(3) would be a rather involved and is currently not high >> on the todolist. A good patch might change that. > >The standard does allow returning NULL, you know. Yes, but unfortunately that broke more software than I cared for arguing with authors about. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-standards@FreeBSD.ORG Mon Mar 1 08:01:18 2004 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7CD0216A4CE for ; Mon, 1 Mar 2004 08:01:18 -0800 (PST) Received: from VARK.homeunix.com (adsl-68-122-0-124.dsl.pltn13.pacbell.net [68.122.0.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CD9D43D31 for ; Mon, 1 Mar 2004 08:01:18 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: from VARK.homeunix.com (localhost [127.0.0.1]) by VARK.homeunix.com (8.12.11/8.12.10) with ESMTP id i21G0MWQ013758; Mon, 1 Mar 2004 08:00:22 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.homeunix.com (8.12.11/8.12.10/Submit) id i21G0MTc013757; Mon, 1 Mar 2004 08:00:22 -0800 (PST) (envelope-from das@FreeBSD.ORG) Date: Mon, 1 Mar 2004 08:00:22 -0800 From: David Schultz To: Poul-Henning Kamp Message-ID: <20040301160022.GA13617@VARK.homeunix.com> Mail-Followup-To: Poul-Henning Kamp , "Dag-Erling =?us-ascii:iso-8859-1?Q?Sm=F8rgrav?=" , stefan@fafoe.narf.at, freebsd-standards@FreeBSD.ORG References: <54807.1078144075@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54807.1078144075@critter.freebsd.dk> cc: stefan@fafoe.narf.at cc: freebsd-standards@FreeBSD.ORG Subject: Re: standards/62858: malloc(0) not C99 compliant 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, 01 Mar 2004 16:01:18 -0000 On Mon, Mar 01, 2004, Poul-Henning Kamp wrote: > In message , Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= > writes: > >Poul-Henning Kamp writes: > >> This is a deliberate choice. Handling zero-size pointers correctly > >> in malloc(3) would be a rather involved and is currently not high > >> on the todolist. A good patch might change that. > > > >The standard does allow returning NULL, you know. > > Yes, but unfortunately that broke more software than I cared for > arguing with authors about. Several other malloc implementations do this, including the one in Tru64. But assuming that there really are lots of broken applications out there, what's wrong with simply converting malloc(0) calls to malloc(1) calls? From owner-freebsd-standards@FreeBSD.ORG Mon Mar 1 08:37:41 2004 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6DC616A4CE; Mon, 1 Mar 2004 08:37:41 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB56E43D39; Mon, 1 Mar 2004 08:37:40 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i21GbVJ4059774; Mon, 1 Mar 2004 17:37:32 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: David Schultz From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 01 Mar 2004 08:00:22 PST." <20040301160022.GA13617@VARK.homeunix.com> Date: Mon, 01 Mar 2004 17:37:31 +0100 Message-ID: <59773.1078159051@critter.freebsd.dk> cc: stefan@fafoe.narf.at cc: freebsd-standards@FreeBSD.ORG Subject: Re: standards/62858: malloc(0) not C99 compliant 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, 01 Mar 2004 16:37:41 -0000 In message <20040301160022.GA13617@VARK.homeunix.com>, David Schultz writes: >On Mon, Mar 01, 2004, Poul-Henning Kamp wrote: >> In message , Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= >> writes: >> >Poul-Henning Kamp writes: >> >> This is a deliberate choice. Handling zero-size pointers correctly >> >> in malloc(3) would be a rather involved and is currently not high >> >> on the todolist. A good patch might change that. >> > >> >The standard does allow returning NULL, you know. >> >> Yes, but unfortunately that broke more software than I cared for >> arguing with authors about. > >Several other malloc implementations do this, including the one in >Tru64. But assuming that there really are lots of broken >applications out there, what's wrong with simply converting >malloc(0) calls to malloc(1) calls? I want to make sure people who malloc(0) and then deref the pointer get the core dump they need to debug their problem. But lets turn this around, do you have evidence of code which breaks with the current behaviour ? Does the code also fail if you give malloc the 'V' flag ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-standards@FreeBSD.ORG Mon Mar 1 11:01:45 2004 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6390516A4E6 for ; Mon, 1 Mar 2004 11:01:45 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 462EA43D1F for ; Mon, 1 Mar 2004 11:01:45 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) i21J1jbv054134 for ; Mon, 1 Mar 2004 11:01:45 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i21J1iZi054128 for freebsd-standards@freebsd.org; Mon, 1 Mar 2004 11:01:44 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 1 Mar 2004 11:01:44 -0800 (PST) Message-Id: <200403011901.i21J1iZi054128@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, 01 Mar 2004 19:01:45 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- s [2001/01/23] misc/24590 standards timezone function not compatible witn Sin o [2001/03/05] bin/25542 standards /bin/sh: null char in quoted string o [2002/02/25] bin/35307 standards standard include files are not standard c o [2003/03/05] bin/48958 standards The type 'bool' has different sizes for C o [2003/04/21] standards/51209standards [PATCH] add a64l()/l64a/l64a_r functions p [2003/06/05] standards/52972standards /bin/sh arithmetic not POSIX compliant o [2003/07/12] standards/54410standards one-true-awk not POSIX compliant (no exte o [2003/09/15] standards/56906standards Several math(3) functions fail to set err o [2003/12/31] standards/60772standards _Bool and bool should be unsigned o [2004/02/05] standards/62388standards sys/resource.h does not pull in dependenc 10 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- f [1995/01/11] i386/105 standards Distributed libm (msun) has non-standard o [2000/09/24] bin/21519 standards sys/dir.h should be deprecated some more o [2000/12/05] kern/23304 standards POSIX clock_gettime, clock_getres return o [2001/01/16] bin/24390 standards Replacing old dir-symlinks when using /bi s [2001/06/18] kern/28260 standards UIO_MAXIOV needs to be made public o [2001/11/20] standards/32126standards getopt(3) not Unix-98 conformant s [2002/03/18] standards/36076standards Implementation of POSIX fuser command o [2002/06/13] standards/39256standards [v]snprintf aren't POSIX-conformant for s o [2002/07/09] misc/40378 standards stdlib.h gives needless warnings with -an p [2002/08/12] standards/41576standards POSIX compliance of ln(1) o [2002/10/23] standards/44425standards getcwd() succeeds even if current dir has o [2002/12/09] standards/46119standards Priority problems for SCHED_OTHER using p o [2002/12/23] standards/46504standards Warnings in headers o [2003/06/22] standards/53613standards FreeBSD doesn't define EPROTO o [2003/06/24] bin/53682 standards [PATCH] add fuser(1) utitity o [2003/07/24] standards/54809standards pcvt deficits o [2003/07/24] standards/54833standards more pcvt deficits o [2003/07/25] standards/54839standards pcvt deficits o [2003/07/31] standards/55112standards glob.h, glob_t's gl_pathc should be "size o [2003/09/04] standards/56476standards cd9660 unicode support simple hack o [2003/09/27] standards/57295standards [patch] make does not include cmd line va o [2003/10/12] standards/57911standards fnmatch ("[[:alpha:]]","x", FNM_PATHNAME) o [2003/10/29] standards/58676standards grantpt(3) alters storage used by ptsname o [2003/11/29] standards/59797standards Implement C99's round[f]() math fucntions p [2003/12/26] standards/60597standards FreeBSD's /usr/include lacks of cpio.h s [2004/02/14] standards/62858standards malloc(0) not C99 compliant p [2004/02/21] standards/63173standards Patch to add getopt_long_only(3) to libc o [2004/02/25] standards/63371standards [patch] isblank() not in C99/SUSv3 namesp 28 problems total. From owner-freebsd-standards@FreeBSD.ORG Tue Mar 2 08:54:13 2004 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63A0516A4CE; Tue, 2 Mar 2004 08:54:13 -0800 (PST) Received: from VARK.homeunix.com (adsl-68-122-0-124.dsl.pltn13.pacbell.net [68.122.0.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9FD843D2F; Tue, 2 Mar 2004 08:54:12 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: from VARK.homeunix.com (localhost [127.0.0.1]) by VARK.homeunix.com (8.12.11/8.12.10) with ESMTP id i22GrNLL021483; Tue, 2 Mar 2004 08:53:24 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.homeunix.com (8.12.11/8.12.10/Submit) id i22GrNiu021482; Tue, 2 Mar 2004 08:53:23 -0800 (PST) (envelope-from das@FreeBSD.ORG) Date: Tue, 2 Mar 2004 08:53:23 -0800 From: David Schultz To: "Jordan K. Hubbard" Message-ID: <20040302165323.GA17665@VARK.homeunix.com> Mail-Followup-To: "Jordan K. Hubbard" , standards@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: cc: standards@FreeBSD.ORG Subject: Re: Another conformance question... This time fputs(). X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2004 16:54:13 -0000 On Tue, Mar 02, 2004, Jordan K. Hubbard wrote: > That gives us this behavior for our little test program: > > errno = 13, rc = -1 > fwrite errno = 13, rc = 0 > > In both cases, we get EACCES for fputs() or fwrite() attempts on a > read-only file pointer pointing to a read-only device, something we'd > expect to get "permission denied" for I think. Nice catch. I think the wording of POSIX suggests that the error code is supposed to be EBADF, which is returned if ``the file descriptor [...] is not a valid file descriptor for writing.'' Although you could argue that the standard is wrong, Linux and Solaris return EBADF, so we probably should, too. (By the way, there are a few other cantwrite() calls in libc that probably have the same bug.) > In the case where we > open the fp for write access, the FreeBSD behavior is unchanged: > > errno = 19, rc = 0 > fwrite errno = 0, rc = 18 > > Which gives us ENODEV for the fputs(3) and no error for the fwrite(3). > I'm not sure why an error is returned at all in the fputs(3) case since > it seems perfectly valid to write onto /dev/null and simply have the > data be discarded, but that error is coming back from somewhere deeper > of the bowels of stdio and has nothing to do with my proposed diff in > any case. Red Hat Linux, interestingly enough, returns errno 25 in > this case (ENOTTY)! I'll bet the isatty() call in __smakebuf() is setting errno because /dev/null doesn't support the relevant ioctl. Note that rc=0 so libc is ignoring the error and completing the write, even though it spuriously sets errno. In any case, you're right that this is an unrelated bug. > This is your libc. This is your libc on SUSv2*. Any questions? ASCII stupid question, get a stupid ANSI. From owner-freebsd-standards@FreeBSD.ORG Tue Mar 2 12:34:36 2004 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB34316A4CE; Tue, 2 Mar 2004 12:34:36 -0800 (PST) Received: from jkh-gw.brierdr.com (adsl-64-173-3-158.dsl.sntc01.pacbell.net [64.173.3.158]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6140743D31; Tue, 2 Mar 2004 12:34:36 -0800 (PST) (envelope-from jkh@queasyweasel.com) Received: from [64.173.15.98] (IDENT:10349-ident-is-a-completely-pointless-protocol-that-offers-no-security-or-traceability-at-all-so-ta@adsl-64-173-15-98.dsl.sntc01.pacbell.net [64.173.15.98]) by jkh-gw.brierdr.com (8.12.10/8.12.10) with ESMTP id i22KXNrF018540; Tue, 2 Mar 2004 12:33:23 -0800 (PST) (envelope-from jkh@queasyweasel.com) In-Reply-To: <20040302165323.GA17665@VARK.homeunix.com> References: <20040302165323.GA17665@VARK.homeunix.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-6--979293609; protocol="application/pkcs7-signature" Message-Id: From: "Jordan K. Hubbard" Date: Tue, 2 Mar 2004 12:33:57 -0800 To: David Schultz X-Mailer: Apple Mail (2.612) X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: standards@FreeBSD.ORG Subject: Re: Another conformance question... This time fputs(). X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2004 20:34:37 -0000 --Apple-Mail-6--979293609 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On Mar 2, 2004, at 8:53 AM, David Schultz wrote: > Nice catch. I think the wording of POSIX suggests that the error > code is supposed to be EBADF, which is returned if ``the file > descriptor [...] is not a valid file descriptor for writing.'' > Although you could argue that the standard is wrong, Linux and > Solaris return EBADF, so we probably should, too. Yeah, that's the approach I just took. Thanks. > (By the way, there are a few other cantwrite() calls in libc that > probably have the same bug.) I've been looking at those... The ones used by the vfprintf() internals look like a no-brainer since the man page says: In addition to the errors documented for the write(2) system call, the printf() family of functions may fail if: [ ... ] Since we've cleverly short-circuited the write(2) calls with the cantwrite() checks, one assumes we're on the hook to emulate what would have happened if we actually had called write(2). I was sort of on the fence about the call in __swbuf(), which is used in the include/stdio.h macros to implement the putc()/putc_unlocked() internals, but I guess there's really no question about it either since http://www.opengroup.org/onlinepubs/007904975/functions/fputc.html is pretty clear that EBADF is expected in the same case. With the full understanding that tabs are going to get smashed in this paste but don't represent what I'd actually commit, does anyone have any objection to the following diff? Index: stdio/vfprintf.c =================================================================== RCS file: /home/ncvs/src/lib/libc/stdio/vfprintf.c,v retrieving revision 1.62 diff -u -r1.62 vfprintf.c --- stdio/vfprintf.c 18 Jan 2004 10:32:49 -0000 1.62 +++ stdio/vfprintf.c 2 Mar 2004 20:31:15 -0000 @@ -50,6 +50,7 @@ #include #include +#include #include #include #include @@ -641,8 +642,10 @@ decimal_point = localeconv()->decimal_point; #endif /* sorry, fprintf(read_only_file, "") returns EOF, not 0 */ - if (cantwrite(fp)) + if (cantwrite(fp)) { + errno = EBADF; return (EOF); + } /* optimise fprintf(stderr) (and other unbuffered Unix files) */ if ((fp->_flags & (__SNBF|__SWR|__SRW)) == (__SNBF|__SWR) && Index: stdio/vfwprintf.c =================================================================== RCS file: /home/ncvs/src/lib/libc/stdio/vfwprintf.c,v retrieving revision 1.16 diff -u -r1.16 vfwprintf.c --- stdio/vfwprintf.c 23 Jan 2004 22:48:16 -0000 1.16 +++ stdio/vfwprintf.c 2 Mar 2004 20:31:16 -0000 @@ -54,6 +54,7 @@ #include #include +#include #include #include #include @@ -646,8 +647,10 @@ #endif convbuf = NULL; /* sorry, fwprintf(read_only_file, L"") returns WEOF, not 0 */ - if (cantwrite(fp)) + if (cantwrite(fp)) { + errno = EBADF; return (EOF); + } /* optimise fprintf(stderr) (and other unbuffered Unix files) */ if ((fp->_flags & (__SNBF|__SWR|__SRW)) == (__SNBF|__SWR) && Index: stdio/wbuf.c =================================================================== RCS file: /home/ncvs/src/lib/libc/stdio/wbuf.c,v retrieving revision 1.10 diff -u -r1.10 wbuf.c --- stdio/wbuf.c 13 Aug 2002 09:30:41 -0000 1.10 +++ stdio/wbuf.c 2 Mar 2004 20:31:16 -0000 @@ -40,6 +40,7 @@ #include __FBSDID("$FreeBSD: src/lib/libc/stdio/wbuf.c,v 1.10 2002/08/13 09:30:41 tjr Exp $"); +#include #include #include "local.h" @@ -65,8 +66,10 @@ * calls might wrap _w from negative to positive. */ fp->_w = fp->_lbfsize; - if (cantwrite(fp)) + if (cantwrite(fp)) { + errno = EBADF; return (EOF); + } c = (unsigned char)c; ORIENT(fp, -1); > I'll bet the isatty() call in __smakebuf() is setting errno > because /dev/null doesn't support the relevant ioctl. Note that > rc=0 so libc is ignoring the error and completing the write, even > though it spuriously sets errno. In any case, you're right that > this is an unrelated bug. No, I don't think that's it (see reply to bde on -arch). I've looked at isatty() and it's fine, it just calls tcgetattr() which sets errno to ENOTTY correctly (I checked). > ASCII stupid question, get a stupid ANSI. UGH!! :-) -- Jordan K. Hubbard Engineering Manager, BSD technology group Apple Computer --Apple-Mail-6--979293609-- From owner-freebsd-standards@FreeBSD.ORG Tue Mar 2 14:40:00 2004 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C696F16A4CE for ; Tue, 2 Mar 2004 14:40:00 -0800 (PST) Received: from laika.ifs.tuwien.ac.at (laika.ifs.tuwien.ac.at [128.131.167.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A8BF43D1F for ; Tue, 2 Mar 2004 14:40:00 -0800 (PST) (envelope-from stefan@fafoe.narf.at) Received: from fafoe.narf.at (unknown [212.186.3.235]) by laika.ifs.tuwien.ac.at (Postfix) with ESMTP id 3964820A9; Tue, 2 Mar 2004 23:42:15 +0100 (CET) Received: from wombat.fafoe.narf.at (wombat.fafoe.narf.at [192.168.1.42]) by fafoe.narf.at (Postfix) with ESMTP id C63A940ED; Tue, 2 Mar 2004 23:39:55 +0100 (CET) Received: by wombat.fafoe.narf.at (Postfix, from userid 1001) id 4453C32A; Tue, 2 Mar 2004 23:39:54 +0100 (CET) Date: Tue, 2 Mar 2004 23:39:54 +0100 From: Stefan Farfeleder To: Poul-Henning Kamp Message-ID: <20040302223950.GF1021@wombat.fafoe.narf.at> Mail-Followup-To: Poul-Henning Kamp , freebsd-standards@FreeBSD.ORG References: <20040301160022.GA13617@VARK.homeunix.com> <59773.1078159051@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <59773.1078159051@critter.freebsd.dk> User-Agent: Mutt/1.5.6i cc: freebsd-standards@FreeBSD.ORG Subject: Re: standards/62858: malloc(0) not C99 compliant X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2004 22:40:00 -0000 On Mon, Mar 01, 2004 at 05:37:31PM +0100, Poul-Henning Kamp wrote: > I want to make sure people who malloc(0) and then deref the pointer get > the core dump they need to debug their problem. So you want malloc(0) to return a different pointer to unmapped memory every time it is called? > But lets turn this around, do you have evidence of code which breaks > with the current behaviour ? I think only conformance checking software will notice this. > Does the code also fail if you give > malloc the 'V' flag ? No, modulo PR bin/62859 where I forgot to CC you :) Cheers, Stefan From owner-freebsd-standards@FreeBSD.ORG Tue Mar 2 15:50:17 2004 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F04FD16A4CE for ; Tue, 2 Mar 2004 15:50:17 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F45043D49 for ; Tue, 2 Mar 2004 15:50:17 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i22NoAu9089172; Wed, 3 Mar 2004 00:50:10 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: Stefan Farfeleder From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 02 Mar 2004 23:39:54 +0100." <20040302223950.GF1021@wombat.fafoe.narf.at> Date: Wed, 03 Mar 2004 00:50:10 +0100 Message-ID: <89171.1078271410@critter.freebsd.dk> cc: freebsd-standards@FreeBSD.ORG Subject: Re: standards/62858: malloc(0) not C99 compliant X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2004 23:50:18 -0000 In message <20040302223950.GF1021@wombat.fafoe.narf.at>, Stefan Farfeleder writes: >On Mon, Mar 01, 2004 at 05:37:31PM +0100, Poul-Henning Kamp wrote: > >> I want to make sure people who malloc(0) and then deref the pointer get >> the core dump they need to debug their problem. > >So you want malloc(0) to return a different pointer to unmapped memory >every time it is called? Yes. >> Does the code also fail if you give >> malloc the 'V' flag ? > >No, modulo PR bin/62859 where I forgot to CC you :) I'll look at this tomorrow if I have time. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-standards@FreeBSD.ORG Tue Mar 2 20:05:03 2004 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5986E16A4CE; Tue, 2 Mar 2004 20:05:03 -0800 (PST) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9765943D1D; Tue, 2 Mar 2004 20:05:02 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])i23451nX023014; Wed, 3 Mar 2004 15:05:01 +1100 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i2344xsJ012090; Wed, 3 Mar 2004 15:05:00 +1100 Date: Wed, 3 Mar 2004 15:04:58 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: David Schultz In-Reply-To: <20040302165323.GA17665@VARK.homeunix.com> Message-ID: <20040303144451.T5253@gamplex.bde.org> References: <20040302165323.GA17665@VARK.homeunix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: standards@freebsd.org cc: "Jordan K. Hubbard" Subject: Re: Another conformance question... This time fputs(). 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, 03 Mar 2004 04:05:03 -0000 On Tue, 2 Mar 2004, David Schultz wrote: > Nice catch. I think the wording of POSIX suggests that the error > code is supposed to be EBADF, which is returned if ``the file > descriptor [...] is not a valid file descriptor for writing.'' > Although you could argue that the standard is wrong, Linux and > Solaris return EBADF, so we probably should, too. I don't think there is any option for fwrite(). Its underlying function is normally write(2) and that would return EBADF (this is what is arguably wrong). fwrite() must do what the underlying function would. > (By the way, there are a few other cantwrite() calls in libc that > probably have the same bug.) One is vfprintf(), which may output to non-files. Oops, so can __svfwrite(). The underlying function isn't always write(2). EBADF is a very bogus errno if the output is not to a file. It can be to a string or anything set up by funopen()/fropen()/fwopen(). Strings are writable, so they don't cause a problem here, but anything set up by fropen() or funopen() without a write function is unwritable and returning EBADF is wrong for it. NetBSD just returns EBADF for all the cantwrite() cases. This incomplete fix was made less than 7 years ago: % RCS file: /home/NetBSD/NetBSD-cvs/src/lib/libc/stdio/fvwrite.c,v % Working file: fvwrite.c % head: 1.15 % ... % ---------------------------- % revision 1.6 % date: 1997/05/03 09:01:48; author: kleink; state: Exp; lines: +6 -3 % Upon an attempt to write to a stream that can't be written to, set errno % to EBADF. % ---------------------------- > > errno = 19, rc = 0 > > fwrite errno = 0, rc = 18 > > > > Which gives us ENODEV for the fputs(3) and no error for the fwrite(3). > ... > I'll bet the isatty() call in __smakebuf() is setting errno > because /dev/null doesn't support the relevant ioctl. Note that > rc=0 so libc is ignoring the error and completing the write, even > though it spuriously sets errno. In any case, you're right that > this is an unrelated bug. Very unrelated. As explained in my earlier reply, rc = 0 indicates an error. errno is not set since we don't support the POSIX extension of setting it. The bug is that ioctls on /dev/zero return a wrong errno (ENODEV instead of ENOTTY). I fixed tens if not hundreds of instances of this bug but never got around to it in the /dev/null family. Bruce From owner-freebsd-standards@FreeBSD.ORG Tue Mar 2 20:12:53 2004 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3097016A4CE; Tue, 2 Mar 2004 20:12:53 -0800 (PST) Received: from jkh-gw.brierdr.com (adsl-64-173-3-158.dsl.sntc01.pacbell.net [64.173.3.158]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDBD043D2D; Tue, 2 Mar 2004 20:12:52 -0800 (PST) (envelope-from jkh@queasyweasel.com) Received: from [64.173.15.98] (IDENT:3220-ident-is-a-completely-pointless-protocol-that-offers-no-security-or-traceability-at-all-so-tak@adsl-64-173-15-98.dsl.sntc01.pacbell.net [64.173.15.98]) by jkh-gw.brierdr.com (8.12.10/8.12.10) with ESMTP id i234CDrF020556; Tue, 2 Mar 2004 20:12:14 -0800 (PST) (envelope-from jkh@queasyweasel.com) In-Reply-To: <20040303144451.T5253@gamplex.bde.org> References: <20040302165323.GA17665@VARK.homeunix.com> <20040303144451.T5253@gamplex.bde.org> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-13--951762788; protocol="application/pkcs7-signature" Message-Id: <0805074F-6CC9-11D8-9000-000393BB9222@queasyweasel.com> From: "Jordan K. Hubbard" Date: Tue, 2 Mar 2004 20:12:48 -0800 To: Bruce Evans X-Mailer: Apple Mail (2.612) X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: standards@freebsd.org cc: David Schultz Subject: Re: Another conformance question... This time fputs(). 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, 03 Mar 2004 04:12:53 -0000 --Apple-Mail-13--951762788 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On Mar 2, 2004, at 8:04 PM, Bruce Evans wrote: > One is vfprintf(), which may output to non-files. Oops, so can > __svfwrite(). The underlying function isn't always write(2). EBADF > is a very bogus errno if the output is not to a file. It can be to a > string or anything set up by funopen()/fropen()/fwopen(). Strings are > writable, so they don't cause a problem here, but anything set up by > fropen() or funopen() without a write function is unwritable and > returning EBADF is wrong for it. So, what fix are you suggesting? I'm truly open to suggestions here, but if all we end up doing at the end of the day is concluding that things are broken but we don't like any of the proposed fixes, we've not really accomplished anything either. I'd more than welcome any diffs to supersede mine. -- Jordan K. Hubbard Engineering Manager, BSD technology group Apple Computer --Apple-Mail-13--951762788-- From owner-freebsd-standards@FreeBSD.ORG Tue Mar 2 21:41:02 2004 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A2CB16A4CE; Tue, 2 Mar 2004 21:41:02 -0800 (PST) Received: from jkh-gw.brierdr.com (adsl-64-173-3-158.dsl.sntc01.pacbell.net [64.173.3.158]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B35043D3F; Tue, 2 Mar 2004 21:41:02 -0800 (PST) (envelope-from jkh@queasyweasel.com) Received: from [64.173.15.98] (IDENT:12194-ident-is-a-completely-pointless-protocol-that-offers-no-security-or-traceability-at-all-so-ta@adsl-64-173-15-98.dsl.sntc01.pacbell.net [64.173.15.98]) by jkh-gw.brierdr.com (8.12.10/8.12.10) with ESMTP id i235eIrF020957; Tue, 2 Mar 2004 21:40:18 -0800 (PST) (envelope-from jkh@queasyweasel.com) Mime-Version: 1.0 (Apple Message framework v612) To: wollman@freebsd.org Message-Id: <561FC4D0-6CD5-11D8-9000-000393BB9222@queasyweasel.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-16--946477790; protocol="application/pkcs7-signature" From: "Jordan K. Hubbard" Date: Tue, 2 Mar 2004 21:40:53 -0800 X-Mailer: Apple Mail (2.612) X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: freebsd-standards@freebsd.org Subject: What's up with /usr/src/usr.bin/alias? 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, 03 Mar 2004 05:41:02 -0000 --Apple-Mail-16--946477790 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed As some people already know, the SUSv2 standards require that a number of commands which are typically implemented as shell built-ins also exist in /usr/bin (for reasons which are at best clear to The Open Group). Unfortunately, the Open Group UNIX conformance test suite also tests that these things actually *work*, which can't be said for FreeBSD's current set, as we can see by the following interaction with /bin/sh: # cat ^Z [1] + Suspended cat # /usr/bin/fg fg: No current job # /usr/bin/jobs # jobs [1] + Suspended cat # fg cat ^D # Using the fg and jobs builtins work, using the "command equivalents" do not. The same is true for things like alias. I suspect this is simply due to the implementation, which invokes the commands in a subshell and thus won't actually work in the context of a test harness which is actually verifying that they did what they said they were going to do afterwards. Naturally, implementing something like "cd" as a command vs a builtin is also pretty darn hard so I'm not saying I don't understand why somebody might have punted on these, I'm simply wondering what the justification for trying to do this at all was given the shortcomings of the chosen approach. -- Jordan K. Hubbard Engineering Manager, BSD technology group Apple Computer --Apple-Mail-16--946477790-- From owner-freebsd-standards@FreeBSD.ORG Wed Mar 3 01:05:27 2004 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0593616A4CE; Wed, 3 Mar 2004 01:05:27 -0800 (PST) Received: from pengo.systems.pipex.net (pengo.systems.pipex.net [62.241.160.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id B08D543D39; Wed, 3 Mar 2004 01:05:26 -0800 (PST) (envelope-from mark@thuvia.org) Received: from dotar.thuvia.org (81-86-74-108.dsl.pipex.com [81.86.74.108]) by pengo.systems.pipex.net (Postfix) with ESMTP id D575D4C00255; Wed, 3 Mar 2004 09:05:23 +0000 (GMT) Received: from dotar.thuvia.org (localhost [127.0.0.1]) by dotar.thuvia.org (8.12.9/8.12.9) with ESMTP id i2395Nag024165; Wed, 3 Mar 2004 09:05:23 GMT (envelope-from mark@dotar.thuvia.org) Received: (from mark@localhost) by dotar.thuvia.org (8.12.9/8.12.9/Submit) id i2395NQk024164; Wed, 3 Mar 2004 09:05:23 GMT (envelope-from mark) Message-Id: <200403030905.i2395NQk024164@dotar.thuvia.org> From: Mark Valentine Date: Wed, 3 Mar 2004 09:05:22 +0000 In-Reply-To: X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: jkh@queasyweasel.com ("Jordan K. Hubbard"), wollman@freebsd.org cc: freebsd-standards@freebsd.org Subject: Re: What's up with /usr/src/usr.bin/alias? 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, 03 Mar 2004 09:05:27 -0000 > From: jkh@queasyweasel.com ("Jordan K. Hubbard") > Date: Tue 2 Mar, 2004 > Subject: What's up with /usr/src/usr.bin/alias? > As some people already know, the SUSv2 standards require that a number > of commands which are typically implemented as shell built-ins also > exist in /usr/bin (for reasons which are at best clear to The Open > Group). Unfortunately, the Open Group UNIX conformance test suite also > tests that these things actually *work*, which can't be said for > FreeBSD's current set, as we can see by the following interaction with > /bin/sh: > > # cat > ^Z > [1] + Suspended cat > # /usr/bin/fg > fg: No current job > # /usr/bin/jobs > # jobs > [1] + Suspended cat > # fg > cat > ^D > # > > Using the fg and jobs builtins work, using the "command equivalents" do > not. What exactly is the test suite testing? SUSv3 has this to say in an informative section: "The jobs utility does not work as expected when it is operating in its own utility execution environment because that environment has no applicable jobs to manipulate. See the APPLICATION USAGE section for bg . For this reason, jobs is generally implemented as a shell regular built-in." So it looks like the examples you tried conform just fine. There are similar paragraphs for cd and so on. Cheers, Mark. -- "Tigers will do ANYTHING for a tuna fish sandwich." "We're kind of stupid that way." *munch* *munch* -- From owner-freebsd-standards@FreeBSD.ORG Wed Mar 3 01:13:28 2004 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC08F16A4CE; Wed, 3 Mar 2004 01:13:28 -0800 (PST) Received: from jkh-gw.brierdr.com (adsl-64-173-3-158.dsl.sntc01.pacbell.net [64.173.3.158]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F6DE43D2D; Wed, 3 Mar 2004 01:13:28 -0800 (PST) (envelope-from jkh@queasyweasel.com) Received: from [64.173.15.98] (IDENT:1269-ident-is-a-completely-pointless-protocol-that-offers-no-security-or-traceability-at-all-so-tak@adsl-64-173-15-98.dsl.sntc01.pacbell.net [64.173.15.98]) by jkh-gw.brierdr.com (8.12.10/8.12.10) with ESMTP id i239CnrF021934; Wed, 3 Mar 2004 01:12:49 -0800 (PST) (envelope-from jkh@queasyweasel.com) In-Reply-To: <200403030905.i2395NQk024164@dotar.thuvia.org> References: <200403030905.i2395NQk024164@dotar.thuvia.org> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-18--933727183; protocol="application/pkcs7-signature" Message-Id: <0613FBAF-6CF3-11D8-9000-000393BB9222@queasyweasel.com> From: "Jordan K. Hubbard" Date: Wed, 3 Mar 2004 01:13:24 -0800 To: Mark Valentine X-Mailer: Apple Mail (2.612) X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: freebsd-standards@freebsd.org cc: wollman@freebsd.org Subject: Re: What's up with /usr/src/usr.bin/alias? 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, 03 Mar 2004 09:13:28 -0000 --Apple-Mail-18--933727183 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On Mar 3, 2004, at 1:05 AM, Mark Valentine wrote: > What exactly is the test suite testing? SUSv3 has this to say in an > informative section: > > "The jobs utility does not work as expected when it is operating > in its own utility execution environment because that environment > has no applicable jobs to manipulate. See the APPLICATION USAGE > section for bg . For this reason, jobs is generally implemented > as a shell regular built-in." > > So it looks like the examples you tried conform just fine. > > There are similar paragraphs for cd and so on. Hmmm! That's interesting... We may have something misconfigured in the conformance test suite which is causing it to flag these. I hadn't read that "informative section" before, but clearly I need to go back and do more research into this. Perhaps we're just missing a DONTBESOANAL environment variable setting. I'll look into this some more, thanks. -- Jordan K. Hubbard Engineering Manager, BSD technology group Apple Computer --Apple-Mail-18--933727183-- From owner-freebsd-standards@FreeBSD.ORG Wed Mar 3 01:19:57 2004 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2662216A4CE; Wed, 3 Mar 2004 01:19:57 -0800 (PST) Received: from pengo.systems.pipex.net (pengo.systems.pipex.net [62.241.160.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4BF843D46; Wed, 3 Mar 2004 01:19:56 -0800 (PST) (envelope-from mark@thuvia.org) Received: from dotar.thuvia.org (81-86-74-108.dsl.pipex.com [81.86.74.108]) by pengo.systems.pipex.net (Postfix) with ESMTP id A0EC34C001A3; Wed, 3 Mar 2004 09:19:54 +0000 (GMT) Received: from dotar.thuvia.org (localhost [127.0.0.1]) by dotar.thuvia.org (8.12.9/8.12.9) with ESMTP id i239Jqag024515; Wed, 3 Mar 2004 09:19:52 GMT (envelope-from mark@dotar.thuvia.org) Received: (from mark@localhost) by dotar.thuvia.org (8.12.9/8.12.9/Submit) id i239JqrO024514; Wed, 3 Mar 2004 09:19:52 GMT (envelope-from mark) Message-Id: <200403030919.i239JqrO024514@dotar.thuvia.org> From: Mark Valentine Date: Wed, 3 Mar 2004 09:19:52 +0000 In-Reply-To: <0613FBAF-6CF3-11D8-9000-000393BB9222@queasyweasel.com> X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: "Jordan K. Hubbard" cc: freebsd-standards@freebsd.org cc: wollman@freebsd.org Subject: Re: What's up with /usr/src/usr.bin/alias? 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, 03 Mar 2004 09:19:57 -0000 > From: "Jordan K. Hubbard" > Date: Wed 3 Mar, 2004 > Subject: Re: What's up with /usr/src/usr.bin/alias? > Hmmm! That's interesting... We may have something misconfigured in > the conformance test suite which is causing it to flag these. On further reading there's additional support for the current behaviour in the introductory section Command Search and Execution: "If the command name contains at least one slash, the shell shall execute the utility in a separate utility environment..." So it's not as if the implementation has to detect that /usr/bin/cd is a built-in or anything. Cheers, Mark. -- "Tigers will do ANYTHING for a tuna fish sandwich." "We're kind of stupid that way." *munch* *munch* -- From owner-freebsd-standards@FreeBSD.ORG Wed Mar 3 01:24:14 2004 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 60C3316A4CE; Wed, 3 Mar 2004 01:24:14 -0800 (PST) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4B7043D39; Wed, 3 Mar 2004 01:24:13 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])i239OCnX029229; Wed, 3 Mar 2004 20:24:12 +1100 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i239O9sJ016323; Wed, 3 Mar 2004 20:24:10 +1100 Date: Wed, 3 Mar 2004 20:24:09 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: "Jordan K. Hubbard" In-Reply-To: <0805074F-6CC9-11D8-9000-000393BB9222@queasyweasel.com> Message-ID: <20040303195618.K1351@gamplex.bde.org> References: <20040303144451.T5253@gamplex.bde.org> <0805074F-6CC9-11D8-9000-000393BB9222@queasyweasel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: standards@freebsd.org cc: David Schultz Subject: Re: Another conformance question... This time fputs(). 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, 03 Mar 2004 09:24:14 -0000 On Tue, 2 Mar 2004, Jordan K. Hubbard wrote: > On Mar 2, 2004, at 8:04 PM, Bruce Evans wrote: > > > One is vfprintf(), which may output to non-files. Oops, so can > > __svfwrite(). The underlying function isn't always write(2). EBADF > > is a very bogus errno if the output is not to a file. It can be to a > > string or anything set up by funopen()/fropen()/fwopen(). Strings are > > writable, so they don't cause a problem here, but anything set up by > > fropen() or funopen() without a write function is unwritable and > > returning EBADF is wrong for it. > > So, what fix are you suggesting? I'm truly open to suggestions here, > but if all we end up doing at the end of the day is concluding that > things are broken but we don't like any of the proposed fixes, we've > not really accomplished anything either. I'd more than welcome any > diffs to supersede mine. We should try to call the underlying function in more cases. This is not so easy since there are flags that may protect whether the underlying function can even be called. Note that cantwrite() already handles some of the details, and could set errno to EBADF more easily than setting it in all callers: % /* % * Return true iff the given FILE cannot be written now. % */ % #define cantwrite(fp) \ % ((((fp)->_flags & __SWR) == 0 || \ % ((fp)->_bf._base == NULL && ((fp)->_flags & __SSTR) == 0)) && \ % __swsetup(fp)) This returns 0 (canwrite) or calls __swsetup() (or both). So __swsetup() always gets a chance to set errno in a context-sensitive way in the cantwrite cases. It doesn't seem to do much errno setting now: % /* % * Various output routines call wsetup to be sure it is safe to write, % * because either _flags does not include __SWR, or _buf is NULL. % * _wsetup returns 0 if OK to write, nonzero otherwise. % */ % int % __swsetup(fp) % FILE *fp; % { % /* make sure stdio is set up */ % if (!__sdidinit) % __sinit(); % % /* % * If we are not writing, we had better be reading and writing. % */ % if ((fp->_flags & __SWR) == 0) { % if ((fp->_flags & __SRW) == 0) % return (EOF); This is the only failure case. It bogusly returns EOF instead of boolean true. We can set errno to EBADF here if we have no idea why __SRW is clear. But we should know. I think the cases are: (1) a normal fopen() for reading only. Then EBADF is correct. (2) funopen() with no writer, or fropen(). I think this can be determined by checking the function pointer that we write through. Then write is just unsupported and an errno like ENOTSUP is better than EBADF. (3) otherwise, we will call the underlying function and there is no problem here. The underlying function just needs to set errno if it fails, and old ones probably don't. So the only immediate problem with returning EBADF in all cases seems to be in case (2) which is not very interesting. % if (fp->_flags & __SRD) { % /* clobber any ungetc data */ % if (HASUB(fp)) % FREEUB(fp); % fp->_flags &= ~(__SRD|__SEOF); % fp->_r = 0; % fp->_p = fp->_bf._base; % } % fp->_flags |= __SWR; % } % % /* % * Make a buffer if necessary, then set _w. % */ % if (fp->_bf._base == NULL) % __smakebuf(fp); % if (fp->_flags & __SLBF) { % /* % * It is line buffered, so make _lbfsize be -_bufsize % * for the putc() macro. We will change _lbfsize back % * to 0 whenever we turn off __SWR. % */ % fp->_w = 0; % fp->_lbfsize = -fp->_bf._size; % } else % fp->_w = fp->_flags & __SNBF ? 0 : fp->_bf._size; % return (0); % } Bruce From owner-freebsd-standards@FreeBSD.ORG Wed Mar 3 08:16:25 2004 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B5BB16A4CE for ; Wed, 3 Mar 2004 08:16:25 -0800 (PST) Received: from VARK.homeunix.com (adsl-68-122-0-124.dsl.pltn13.pacbell.net [68.122.0.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7104343D1F for ; Wed, 3 Mar 2004 08:16:25 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: from VARK.homeunix.com (localhost [127.0.0.1]) by VARK.homeunix.com (8.12.11/8.12.10) with ESMTP id i23GFXxf027400; Wed, 3 Mar 2004 08:15:33 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.homeunix.com (8.12.11/8.12.10/Submit) id i23GFWcI027399; Wed, 3 Mar 2004 08:15:32 -0800 (PST) (envelope-from das@FreeBSD.ORG) Date: Wed, 3 Mar 2004 08:15:32 -0800 From: David Schultz To: Bruce Evans Message-ID: <20040303161532.GA27304@VARK.homeunix.com> Mail-Followup-To: Bruce Evans , "Jordan K. Hubbard" , standards@FreeBSD.ORG References: <20040302165323.GA17665@VARK.homeunix.com> <20040303144451.T5253@gamplex.bde.org> <0805074F-6CC9-11D8-9000-000393BB9222@queasyweasel.com> <20040303195618.K1351@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040303195618.K1351@gamplex.bde.org> cc: standards@FreeBSD.ORG Subject: Re: Another conformance question... This time fputs(). 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, 03 Mar 2004 16:16:25 -0000 On Wed, Mar 03, 2004, Bruce Evans wrote: > This is the only failure case. It bogusly returns EOF instead of boolean > true. We can set errno to EBADF here if we have no idea why __SRW is > clear. But we should know. I think the cases are: > (1) a normal fopen() for reading only. Then EBADF is correct. > (2) funopen() with no writer, or fropen(). I think this can be determined > by checking the function pointer that we write through. Then write is > just unsupported and an errno like ENOTSUP is better than EBADF. > (3) otherwise, we will call the underlying function and there is no problem > here. The underlying function just needs to set errno if it fails, and > old ones probably don't. > So the only immediate problem with returning EBADF in all cases seems to be > in case (2) which is not very interesting. One could argue that EBADF is a perfectly reasonable error code to return in case (2) as well. It is consistent with the way other types of stdio streams work. Specifically, if the stream isn't writable (either because it was opened read-only and we don't have permission or because it was opened without a writefn and we don't support it) then we should get a single error code that reflects the fact that the stream isn't writable. The fputs(3) man page even says: [EBADF] The _stream_ argument is not a writable stream. It doesn't say anything about why the stream is not writable. Thus, there shouldn't be a problem with simply setting errno to EBADF in all failure cases in __swsetup(). From owner-freebsd-standards@FreeBSD.ORG Wed Mar 3 12:21:56 2004 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A55D616A4CE; Wed, 3 Mar 2004 12:21:56 -0800 (PST) Received: from jkh-gw.brierdr.com (adsl-64-173-3-158.dsl.sntc01.pacbell.net [64.173.3.158]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A70F43D5D; Wed, 3 Mar 2004 12:21:56 -0800 (PST) (envelope-from jkh@queasyweasel.com) Received: from [64.173.15.98] (IDENT:15686-ident-is-a-completely-pointless-protocol-that-offers-no-security-or-traceability-at-all-so-ta@adsl-64-173-15-98.dsl.sntc01.pacbell.net [64.173.15.98]) by jkh-gw.brierdr.com (8.12.10/8.12.10) with ESMTP id i23KLFrF024880; Wed, 3 Mar 2004 12:21:15 -0800 (PST) (envelope-from jkh@queasyweasel.com) In-Reply-To: <20040303161532.GA27304@VARK.homeunix.com> References: <20040302165323.GA17665@VARK.homeunix.com> <20040303144451.T5253@gamplex.bde.org> <0805074F-6CC9-11D8-9000-000393BB9222@queasyweasel.com> <20040303195618.K1351@gamplex.bde.org> <20040303161532.GA27304@VARK.homeunix.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6759E5CE-6D50-11D8-9000-000393BB9222@queasyweasel.com> Content-Transfer-Encoding: 7bit From: "Jordan K. Hubbard" Date: Wed, 3 Mar 2004 12:21:50 -0800 To: David Schultz X-Mailer: Apple Mail (2.612) cc: standards@FreeBSD.ORG Subject: Re: Another conformance question... This time fputs(). 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, 03 Mar 2004 20:21:56 -0000 On Mar 3, 2004, at 8:15 AM, David Schultz wrote: > One could argue that EBADF is a perfectly reasonable error code to > return in case (2) as well. It is consistent with the way other > types of stdio streams work. Specifically, if the stream isn't > writable (either because it was opened read-only and we don't have > permission or because it was opened without a writefn and we don't > support it) then we should get a single error code that reflects > the fact that the stream isn't writable. The fputs(3) man page > even says: > > [EBADF] The _stream_ argument is not a writable stream. > > It doesn't say anything about why the stream is not writable. > Thus, there shouldn't be a problem with simply setting errno to > EBADF in all failure cases in __swsetup(). I agree. So, do you want to make the 2nd round of changes or shall I? -- Jordan K. Hubbard Engineering Manager, BSD technology group Apple Computer From owner-freebsd-standards@FreeBSD.ORG Wed Mar 3 19:22:17 2004 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 810F816A4CF; Wed, 3 Mar 2004 19:22:17 -0800 (PST) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id C415A43D31; Wed, 3 Mar 2004 19:22:16 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])i243MCnX023033; Thu, 4 Mar 2004 14:22:12 +1100 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i243MA5c032424; Thu, 4 Mar 2004 14:22:11 +1100 Date: Thu, 4 Mar 2004 14:22:09 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: David Schultz In-Reply-To: <20040303161532.GA27304@VARK.homeunix.com> Message-ID: <20040304140533.Y5030@gamplex.bde.org> References: <20040303144451.T5253@gamplex.bde.org> <0805074F-6CC9-11D8-9000-000393BB9222@queasyweasel.com> <20040303161532.GA27304@VARK.homeunix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: standards@freebsd.org Subject: Re: Another conformance question... This time fputs(). 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, 04 Mar 2004 03:22:17 -0000 On Wed, 3 Mar 2004, David Schultz wrote: > On Wed, Mar 03, 2004, Bruce Evans wrote: > > This is the only failure case. It bogusly returns EOF instead of boolean > > true. We can set errno to EBADF here if we have no idea why __SRW is > > clear. But we should know. I think the cases are: > > (1) a normal fopen() for reading only. Then EBADF is correct. > > (2) funopen() with no writer, or fropen(). I think this can be determined > > by checking the function pointer that we write through. Then write is > > just unsupported and an errno like ENOTSUP is better than EBADF. > > (3) otherwise, we will call the underlying function and there is no problem > > here. The underlying function just needs to set errno if it fails, and > > old ones probably don't. > > So the only immediate problem with returning EBADF in all cases seems to be > > in case (2) which is not very interesting. > > One could argue that EBADF is a perfectly reasonable error code to > return in case (2) as well. It is consistent with the way other > types of stdio streams work. Specifically, if the stream isn't > writable (either because it was opened read-only and we don't have > permission or because it was opened without a writefn and we don't > support it) then we should get a single error code that reflects > the fact that the stream isn't writable. The fputs(3) man page > even says: > > [EBADF] The _stream_ argument is not a writable stream. > > It doesn't say anything about why the stream is not writable. > Thus, there shouldn't be a problem with simply setting errno to > EBADF in all failure cases in __swsetup(). I would argue that that is a bug in the fputs man page. It clearly doesn't consider the case of funopen()'d streams, and fputs() never actually set errno to EBADF like the man page says. However, errno is set EBADF is set explicitly in several other places irrespective of the destination of the output, and its too late too change all of these and wrong to be inconstent with them: fclose: EOF/EBADF if the stream is not open fflush: EOF/EBADF if the stream is not writable fpurge: EOF/EBADF if the stream is not open __fvwrite: recently changed __srefil: EOF/EBADF if the stream is not open for reading. __srefil is similar to the function behind cantwrite(), namely __swsetup, except it is for reading instead of writing and it sets EBADF. The man page for fflush and fpurge documents EBADF explicitly, but the man page for fclose only has generalities about errno. Bruce From owner-freebsd-standards@FreeBSD.ORG Wed Mar 3 21:35:36 2004 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A495A16A4CE for ; Wed, 3 Mar 2004 21:35:36 -0800 (PST) Received: from VARK.homeunix.com (adsl-68-122-0-124.dsl.pltn13.pacbell.net [68.122.0.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7764343D1D for ; Wed, 3 Mar 2004 21:35:36 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: from VARK.homeunix.com (localhost [127.0.0.1]) by VARK.homeunix.com (8.12.11/8.12.10) with ESMTP id i245YgJQ030637; Wed, 3 Mar 2004 21:34:42 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.homeunix.com (8.12.11/8.12.10/Submit) id i245YgCG030636; Wed, 3 Mar 2004 21:34:42 -0800 (PST) (envelope-from das@FreeBSD.ORG) Date: Wed, 3 Mar 2004 21:34:42 -0800 From: David Schultz To: "Jordan K. Hubbard" Message-ID: <20040304053442.GA30305@VARK.homeunix.com> Mail-Followup-To: "Jordan K. Hubbard" , standards@FreeBSD.ORG, Bruce Evans References: <20040302165323.GA17665@VARK.homeunix.com> <20040303144451.T5253@gamplex.bde.org> <0805074F-6CC9-11D8-9000-000393BB9222@queasyweasel.com> <20040303195618.K1351@gamplex.bde.org> <20040303161532.GA27304@VARK.homeunix.com> <6759E5CE-6D50-11D8-9000-000393BB9222@queasyweasel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6759E5CE-6D50-11D8-9000-000393BB9222@queasyweasel.com> cc: standards@FreeBSD.ORG Subject: Re: Another conformance question... This time fputs(). 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, 04 Mar 2004 05:35:36 -0000 On Wed, Mar 03, 2004, Jordan K. Hubbard wrote: > > On Mar 3, 2004, at 8:15 AM, David Schultz wrote: > > >One could argue that EBADF is a perfectly reasonable error code to > >return in case (2) as well. It is consistent with the way other > >types of stdio streams work. Specifically, if the stream isn't > >writable (either because it was opened read-only and we don't have > >permission or because it was opened without a writefn and we don't > >support it) then we should get a single error code that reflects > >the fact that the stream isn't writable. The fputs(3) man page > >even says: > > > > [EBADF] The _stream_ argument is not a writable stream. > > > >It doesn't say anything about why the stream is not writable. > >Thus, there shouldn't be a problem with simply setting errno to > >EBADF in all failure cases in __swsetup(). > > I agree. Bruce doesn't seem to be happy with either this suggestion or the status quo, but he did point out that fclose(), fflush(), fpurge(), __fvwrite(), and __srefill() share this ``bug'' of setting errno to EBADF. > So, do you want to make the 2nd round of changes or shall I? I'd be happy to do it, but I'm going to be out of town a lot this month, so it might take me another three weeks if I can't find a big enough FreeBSD timeslice in my schedule next week. So if you want it done *soon*, you should probably do it. ;-) From owner-freebsd-standards@FreeBSD.ORG Sat Mar 6 09:32:22 2004 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F7C016A4CE; Sat, 6 Mar 2004 09:32:22 -0800 (PST) Received: from numeri.campus.luth.se (numeri.campus.luth.se [130.240.197.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1C5C43D45; Sat, 6 Mar 2004 09:32:21 -0800 (PST) (envelope-from k@numeri.campus.luth.se) Received: from numeri.campus.luth.se (localhost [127.0.0.1]) i26HWJT9074142; Sat, 6 Mar 2004 18:32:19 +0100 (CET) (envelope-from k@numeri.campus.luth.se) Received: (from k@localhost) by numeri.campus.luth.se (8.12.10/8.12.10/Submit) id i26HWJJM074141; Sat, 6 Mar 2004 18:32:19 +0100 (CET) (envelope-from k) Date: Sat, 6 Mar 2004 18:32:19 +0100 From: Johan Karlsson To: Luigi Rizzo Message-ID: <20040306173219.GB64109@numeri.campus.luth.se> References: <20040306111922.GA64109@numeri.campus.luth.se> <20040306082625.B34490@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040306082625.B34490@xorpc.icir.org> User-Agent: Mutt/1.4.1i cc: standards@freebsd.org Subject: where do %j/uintmax_t stand in terms of standards? [WAS: Re: WARNS cleanup for ipfw 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: Sat, 06 Mar 2004 17:32:22 -0000 [lets move this from ipfw@ to standars@ to get an answer] On Sat, Mar 06, 2004 at 08:26 (-0800) +0000, Luigi Rizzo wrote: > On Sat, Mar 06, 2004 at 12:19:22PM +0100, Johan Karlsson wrote: > > Hi > > > > the attached patch makes ipfw WARNS=2 clean by using the > > %j/(uintmax_t) combo where so needed. If there are no > > objections I intend to commit this patch. First of all, %j/uintmax_t is used since uint64_t does not match long long on all our platforms. Hence to print this without warning we need to do this. > > if align_uint64() is always cast to uintmax_t, why don't > you define it to return the proper type instead ? Since I only looked at removing the warnings I did not realize that it is only used when printing. However, I do agree that this is a better solution. I will make that change and run it through a make universe. > > Also, where do %j/uintmax_t stand in terms of standards ? > certainly the gcc in 4.x does not like them... I have absolutly no idea. Can someone here at standards@ answer this question? take care /Johan K -- Johan Karlsson mailto:johan@FreeBSD.org From owner-freebsd-standards@FreeBSD.ORG Sat Mar 6 09:42:41 2004 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A384816A4CE for ; Sat, 6 Mar 2004 09:42:41 -0800 (PST) Received: from falcon.midgard.homeip.net (h201n1fls24o1048.bredband.comhem.se [212.181.162.201]) by mx1.FreeBSD.org (Postfix) with SMTP id D704543D2F for ; Sat, 6 Mar 2004 09:42:39 -0800 (PST) (envelope-from ertr1013@student.uu.se) Received: (qmail 28908 invoked by uid 1001); 6 Mar 2004 17:42:38 -0000 Date: Sat, 6 Mar 2004 18:42:38 +0100 From: Erik Trulsson To: Johan Karlsson Message-ID: <20040306174237.GA28880@falcon.midgard.homeip.net> Mail-Followup-To: Johan Karlsson , Luigi Rizzo , standards@freebsd.org References: <20040306111922.GA64109@numeri.campus.luth.se> <20040306082625.B34490@xorpc.icir.org> <20040306173219.GB64109@numeri.campus.luth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040306173219.GB64109@numeri.campus.luth.se> User-Agent: Mutt/1.5.6i cc: Luigi Rizzo cc: standards@freebsd.org Subject: Re: where do %j/uintmax_t stand in terms of standards? [WAS: Re: WARNS cleanup for ipfw 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: Sat, 06 Mar 2004 17:42:41 -0000 On Sat, Mar 06, 2004 at 06:32:19PM +0100, Johan Karlsson wrote: > [lets move this from ipfw@ to standars@ to get an answer] > > > On Sat, Mar 06, 2004 at 08:26 (-0800) +0000, Luigi Rizzo wrote: > > > > Also, where do %j/uintmax_t stand in terms of standards ? > > certainly the gcc in 4.x does not like them... > > I have absolutly no idea. Can someone here at standards@ answer > this question? %j/uintmax_t are part of C99 (but not C89) so they are standard. However gcc 2.95 (which is what FreeBSD 4.x ships with) does not support C99 so it is not surprising if it complains. -- Erik Trulsson ertr1013@student.uu.se