From owner-freebsd-standards@FreeBSD.ORG Mon Oct 27 05:49:54 2003 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 1172416A4B3; Mon, 27 Oct 2003 05:49:54 -0800 (PST) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FA9543FBF; Mon, 27 Oct 2003 05:49:52 -0800 (PST) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h9RDnpP13160; Mon, 27 Oct 2003 14:49:51 +0100 (MET) Date: Mon, 27 Oct 2003 14:49:51 +0100 (CET) From: Harti Brandt To: sparc64@freebsd.org, standards@freebsd.org Message-ID: <20031027144140.V63585@beagle.fokus.fraunhofer.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: 64bit NULL? 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, 27 Oct 2003 13:49:54 -0000 Hi all, a question came up wether the NULL should be defined as (0L) on sparc. (Solaris does this). Currently we define NULL as 0. This may cause problems for function with variable argument lists that expect a terminating NULL pointer. A prominent example is execl(). Although POSIX (and our man page) gives the synopsis execl(...., (char *)0) our man pages says that the list must be terminated by a NULL pointer, POSIX speaks 'null pointer'. According to ISO-C NULL is a symbol that defines a null pointer so that: execl(..., NULL) appears to be legal, yet will probably cause failure on FreeBSD-sparc64. Shouldn't we change our NULL definition to #define NULL (0L) ? What would break by this change? Regards, harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-standards@FreeBSD.ORG Mon Oct 27 06:11:25 2003 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 582B816A4BF; Mon, 27 Oct 2003 06:11:25 -0800 (PST) Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9D0543FD7; Mon, 27 Oct 2003 06:11:24 -0800 (PST) (envelope-from fanf@chiark.greenend.org.uk) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local id 1AE85b-00046m-00; Mon, 27 Oct 2003 14:11:23 +0000 Date: Mon, 27 Oct 2003 14:11:23 +0000 From: Tony Finch To: Harti Brandt Message-ID: <20031027141123.GB22725@chiark.greenend.org.uk> References: <20031027144140.V63585@beagle.fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031027144140.V63585@beagle.fokus.fraunhofer.de> User-Agent: Mutt/1.3.28i Sender: Tony Finch cc: standards@freebsd.org cc: sparc64@freebsd.org Subject: Re: 64bit NULL? 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, 27 Oct 2003 14:11:25 -0000 On Mon, Oct 27, 2003 at 02:49:51PM +0100, Harti Brandt wrote: > > According to ISO-C NULL is a symbol that > defines a null pointer so that: > > execl(..., NULL) > > appears to be legal, yet will probably cause failure on FreeBSD-sparc64. No, NULL is an implementation-defined null pointer constant, not a null pointer. The difference is that a null pointer constant is an integer constant expression that evaluates to zero (optionally cast to void*), and a null pointer is a null pointer constant converted to a pointer type (which might involve changes in representation). Therefore using a bare NULL to terminate the execl argument list is not in general legal. Tony. -- f.a.n.finch http://dotat.at/ GERMAN BIGHT: SOUTHWEST 5 OR 6. OCCASIONAL RAIN. MODERATE OR GOOD. From owner-freebsd-standards@FreeBSD.ORG Mon Oct 27 06:23:18 2003 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 EC99316A4B3; Mon, 27 Oct 2003 06:23:18 -0800 (PST) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2EF4043F75; Mon, 27 Oct 2003 06:23:17 -0800 (PST) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h9REN3P16911; Mon, 27 Oct 2003 15:23:03 +0100 (MET) Date: Mon, 27 Oct 2003 15:23:03 +0100 (CET) From: Harti Brandt To: Tony Finch In-Reply-To: <20031027141123.GB22725@chiark.greenend.org.uk> Message-ID: <20031027152139.C63585@beagle.fokus.fraunhofer.de> References: <20031027144140.V63585@beagle.fokus.fraunhofer.de> <20031027141123.GB22725@chiark.greenend.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: standards@freebsd.org cc: sparc64@freebsd.org Subject: Re: 64bit NULL? 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, 27 Oct 2003 14:23:19 -0000 On Mon, 27 Oct 2003, Tony Finch wrote: TF>On Mon, Oct 27, 2003 at 02:49:51PM +0100, Harti Brandt wrote: TF>> TF>> According to ISO-C NULL is a symbol that TF>> defines a null pointer so that: TF>> TF>> execl(..., NULL) TF>> TF>> appears to be legal, yet will probably cause failure on FreeBSD-sparc64. TF> TF>No, NULL is an implementation-defined null pointer constant, not a null TF>pointer. The difference is that a null pointer constant is an integer TF>constant expression that evaluates to zero (optionally cast to void*), TF>and a null pointer is a null pointer constant converted to a pointer type TF>(which might involve changes in representation). Therefore using a bare TF>NULL to terminate the execl argument list is not in general legal. Thanks, Tony. I found the relevant place (6.3.2.3). This sounds logical. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-standards@FreeBSD.ORG Mon Oct 27 06:29:46 2003 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 9B6F616A4B3 for ; Mon, 27 Oct 2003 06:29:46 -0800 (PST) Received: from falcon.midgard.homeip.net (h76n3fls24o1048.bredband.comhem.se [213.67.148.76]) by mx1.FreeBSD.org (Postfix) with SMTP id 4120743FCB for ; Mon, 27 Oct 2003 06:29:43 -0800 (PST) (envelope-from ertr1013@student.uu.se) Received: (qmail 98737 invoked by uid 1001); 27 Oct 2003 14:29:40 -0000 Date: Mon, 27 Oct 2003 15:29:40 +0100 From: Erik Trulsson To: Harti Brandt Message-ID: <20031027142940.GA85871@falcon.midgard.homeip.net> Mail-Followup-To: Harti Brandt , sparc64@freebsd.org, standards@freebsd.org References: <20031027144140.V63585@beagle.fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031027144140.V63585@beagle.fokus.fraunhofer.de> User-Agent: Mutt/1.5.4i cc: standards@freebsd.org cc: sparc64@freebsd.org Subject: Re: 64bit NULL? 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, 27 Oct 2003 14:29:46 -0000 On Mon, Oct 27, 2003 at 02:49:51PM +0100, Harti Brandt wrote: > > Hi all, > > a question came up wether the NULL should be defined as (0L) on sparc. > (Solaris does this). Currently we define NULL as 0. This may cause Both are perfectly good definitions of NULL. All correct programs must be able to handle either definition as well as being able to handle NULL being defined as ((void*)0) which is also a correct and fairly popular way of defining NULL (although it is not a valid definition in C++.) > problems for function with variable argument lists that expect a > terminating NULL pointer. A prominent example is execl(). Although POSIX Only for buggy invocations of such functions. > (and our man page) gives the synopsis > > execl(...., (char *)0) Looks correct. > > our man pages says that the list must be terminated by a NULL pointer, > POSIX speaks 'null pointer'. Correct. > According to ISO-C NULL is a symbol that > defines a null pointer so that: Wrong. ISO C defines NULL as 'null pointer constant'. This is not the same thing as a null pointer. >From n869.txt (a draft version of the C99 standard) 6.3.2.3 Pointers .... [#3] An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant.48) If a null pointer constant is | converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function. .... 48)The macro NULL is defined in as a null pointer constant; see 7.17. > > execl(..., NULL) > > appears to be legal, yet will probably cause failure on FreeBSD-sparc64. But is is not legal. If you pass NULL as an argument to a function with variable arguments, or to a function that does not have a prototype in scope (in neither case does the compiler know what type the argument should have, so it won't convert it for you) you must convert NULL to the correct pointer type. > Shouldn't we change our NULL definition to > > #define NULL (0L) No good reason to. > > ? What would break by this change? It would hide some bugs in programs that (incorrectly) assume that NULL can be used in any place that a null pointer is needed. Hiding bugs is rarely a good thing, since the bugs are less likely to be fixed then. It would of course also break the same buggy programs if used on a system where long does not have the same size or representation as a pointer. -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-standards@FreeBSD.ORG Mon Oct 27 11:01:50 2003 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 F117B16A4B3 for ; Mon, 27 Oct 2003 11:01:50 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C7DF43FF7 for ; Mon, 27 Oct 2003 11:01:41 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h9RJ1eFY056715 for ; Mon, 27 Oct 2003 11:01:40 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h9RJ1eil056710 for freebsd-standards@freebsd.org; Mon, 27 Oct 2003 11:01:40 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 27 Oct 2003 11:01:40 -0800 (PST) Message-Id: <200310271901.h9RJ1eil056710@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, 27 Oct 2003 19:01:51 -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 [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/06/20] standards/53554standards interval timers not cleared in fork() 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 8 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2001/01/16] bin/24390 standards Replacing old dir-symlinks when using /bi 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/04/22] standards/51292standards [PATCH] add ecvt()/fcvt()/gcvt() function 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/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) 18 problems total. From owner-freebsd-standards@FreeBSD.ORG Mon Oct 27 11:03:26 2003 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 3768016A4BF for ; Mon, 27 Oct 2003 11:03:26 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22CB143F75 for ; Mon, 27 Oct 2003 11:03:25 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h9RJ3PFY058833 for ; Mon, 27 Oct 2003 11:03:25 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h9RJ3Oat058827 for standards@freebsd.org; Mon, 27 Oct 2003 11:03:24 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 27 Oct 2003 11:03:24 -0800 (PST) Message-Id: <200310271903.h9RJ3Oat058827@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: 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, 27 Oct 2003 19:03:26 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2001/08/18] kern/29844 standards [PATCH] setpgrp does not behave as manual 1 problem total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2001/03/05] bin/25542 standards /bin/sh: null char in quoted string 1 problem 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 s [2001/06/18] kern/28260 standards UIO_MAXIOV needs to be made public 4 problems total. From owner-freebsd-standards@FreeBSD.ORG Wed Oct 29 01:10:20 2003 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 74C1416A4CE for ; Wed, 29 Oct 2003 01:10:20 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 040C843FB1 for ; Wed, 29 Oct 2003 01:10:19 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h9T9AIFY015426 for ; Wed, 29 Oct 2003 01:10:18 -0800 (PST) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h9T9AIvj015425; Wed, 29 Oct 2003 01:10:18 -0800 (PST) (envelope-from gnats) Resent-Date: Wed, 29 Oct 2003 01:10:18 -0800 (PST) Resent-Message-Id: <200310290910.h9T9AIvj015425@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-standards@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Ryan Younce Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 11CF716A4CE for ; Wed, 29 Oct 2003 01:07:16 -0800 (PST) Received: from turing.vangyzen.net (turing.vangyzen.net [152.3.22.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70E7F43F3F for ; Wed, 29 Oct 2003 01:07:15 -0800 (PST) (envelope-from ryan@turing.vangyzen.net) Received: by turing.vangyzen.net (Postfix, from userid 1010) id CD2A71145D; Wed, 29 Oct 2003 04:07:14 -0500 (EST) Message-Id: <20031029090714.CD2A71145D@turing.vangyzen.net> Date: Wed, 29 Oct 2003 04:07:14 -0500 (EST) From: Ryan Younce To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Subject: standards/58676: grantpt(3) alters storage used by ptsname(3) X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Ryan Younce List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2003 09:10:20 -0000 >Number: 58676 >Category: standards >Synopsis: grantpt(3) alters storage used by ptsname(3) >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-standards >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Oct 29 01:10:18 PST 2003 >Closed-Date: >Last-Modified: >Originator: Ryan Younce >Release: FreeBSD 5.1-RELEASE >Organization: >Environment: FreeBSD kara 5.1-RELEASE FreeBSD 5.1-RELEASE #3: Mon Oct 6 22:31:51 GMT 2003 root@kara:/usr/src/sys/i386/compile/KARA i386 >Description: The ptsname(3) function is allowed by POSIX to hold the returned slave PTY name in static storage that may be overwritten by subsequent calls to ptsname() (which it does). In the current implementation, however, grantpt(3) calls ptsname() to obtain the name of the slave device. Hence, a call to grantpt() will alter the object returned by a previous ptsname() if grantpt() is called with a different descriptor than the one used in the last call to ptsname(). This is incorrect; POSIX makes no mention that the returned object of ptsname() may be modified by subsequent calls to grantpt(). >How-To-Repeat: #include #include #include int main(void) { char *slave; int fd1, fd2; fd1 = posix_openpt(0); fd2 = posix_openpt(0); slave = ptsname(fd1); printf("fd1 slave name (before grantpt(fd2)): '%s'\n", slave); /* call grantpt(3) on fd2 */ grantpt(fd2); /* print out slave again, which should not have changed */ printf("fd1 slave name (after grantpt(fd2)): '%s'\n", slave); return 0; } >Fix: Moved the code that obtains the name of the PTY slave from the master's descriptor into a separate (internal) function, derive_slave(), that is called by both grantpt() and ptsname(). (As a side, the manual page should be updated to reflect that ptsname() holds its return in static storage that may be overwritten by subsequent calls to ptsname().) The following are patches to both files. Index: grantpt.c =================================================================== RCS file: /home/ncvs/src/lib/libc/stdlib/grantpt.c,v retrieving revision 1.2 diff -u -r1.2 grantpt.c --- grantpt.c 4 Jan 2003 08:10:55 -0000 1.2 +++ grantpt.c 27 Oct 2003 06:21:45 -0000 @@ -81,6 +81,27 @@ minor((x).st_rdev) >= 0 && \ minor((x).st_rdev) < PT_MAX) +static char * +derive_slave(int fildes, char *slave) +{ + struct stat sbuf; + char *retname = NULL; + + if (_fstat(fildes, &sbuf) == 0) { + /* Ensure fildes is a master PTY device */ + if (!ISPTM(sbuf)) + errno = EINVAL; + else { + /* Translate fildes into path to counterpart slave. */ + (void)sprintf(slave, _PATH_DEV PTS_PREFIX "%c%c", + PT_DEV1[minor(sbuf.st_rdev) / 32], + PT_DEV2[minor(sbuf.st_rdev) % 32]); + retname = slave; + } + } + return retname; +} + /* * grantpt(): grant ownership of a slave pseudo-terminal device to the * current user. @@ -92,14 +113,14 @@ int retval, serrno, status; pid_t pid, spid; gid_t gid; - char *slave; + char slave[] = _PATH_DEV PTS_PREFIX "XY"; sigset_t oblock, nblock; struct group *grp; retval = -1; serrno = errno; - if ((slave = ptsname(fildes)) != NULL) { + if (derive_slave(fildes, slave) != NULL) { /* * Block SIGCHLD. */ @@ -217,23 +238,7 @@ ptsname(int fildes) { static char slave[] = _PATH_DEV PTS_PREFIX "XY"; - char *retval; - struct stat sbuf; - - retval = NULL; - - if (_fstat(fildes, &sbuf) == 0) { - if (!ISPTM(sbuf)) - errno = EINVAL; - else { - (void)sprintf(slave, _PATH_DEV PTS_PREFIX "%c%c", - PT_DEV1[minor(sbuf.st_rdev) / 32], - PT_DEV2[minor(sbuf.st_rdev) % 32]); - retval = slave; - } - } - - return (retval); + return derive_slave(fildes, slave); } /* Index: grantpt.3 =================================================================== RCS file: /home/ncvs/src/lib/libc/stdlib/grantpt.3,v retrieving revision 1.3 diff -u -r1.3 grantpt.3 --- grantpt.3 14 Sep 2003 13:41:57 -0000 1.3 +++ grantpt.3 27 Oct 2003 06:21:45 -0000 @@ -211,6 +211,14 @@ .Fn posix_openpt functions appeared in .Fx 5.0 . +.Sh BUGS +The function +.Fn ptsname +leaves its result in an internal static object and returns +a pointer to that object. +Subsequent calls to +.Fn ptsname +will modify the same object. .Sh NOTES The purpose of the .Fn unlockpt >Release-Note: >Audit-Trail: >Unformatted: