From sacadmin Wed Jul 28 15:54:50 2010 Received: from antilock3.sfbay.sun.com (antilock3.SFBay.Sun.COM [10.5.240.66]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o6SMsoB1003647; Wed, 28 Jul 2010 15:54:50 -0700 (PDT) Received: from antilock3.sfbay.sun.com (localhost [127.0.0.1]) by antilock3.sfbay.sun.com (8.14.4+Sun/8.14.4) with ESMTP id o6SMsmNn344633; Wed, 28 Jul 2010 15:54:48 -0700 (PDT) Received: (from raf@localhost) by antilock3.sfbay.sun.com (8.14.4+Sun/8.14.4/Submit) id o6SMsmOU344630; Wed, 28 Jul 2010 15:54:48 -0700 (PDT) Date: Wed, 28 Jul 2010 15:54:48 -0700 (PDT) From: "Roger A. Faulkner" Message-Id: <201007282254.o6SMsmOU344630@antilock3.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Cc: jeff.bonwick@Oracle.COM, scott.michael@Oracle.COM Subject: GNU/Linux/BSD compatibility functions [PSARC/2010/299 FastTrack timeout 08/04/2010] Status: RO Content-Length: 615 Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. 1. Introduction 1.1. Project/Component Working Name: GNU/Linux/BSD compatibility functions 1.2. Name of Document Author/Supplier: Author: Roger Faulkner 1.3 Date of This Document: 28 July, 2010 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: OS/NET 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From roger.faulkner@oracle.com Wed Jul 28 16:42:09 2010 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o6SNg9wA004831 for ; Wed, 28 Jul 2010 16:42:09 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o6SNg8mg015306 for ; Wed, 28 Jul 2010 16:42:08 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o6SNg88I014871 for ; Wed, 28 Jul 2010 23:42:08 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6SNg6Lh004934 for ; Wed, 28 Jul 2010 23:42:07 GMT Received: from abhmt013.oracle.com by acsmt354.oracle.com with ESMTP id 466043171280360498; Wed, 28 Jul 2010 16:41:38 -0700 Received: from [10.7.251.247] (/10.7.251.247) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 28 Jul 2010 16:41:38 -0700 Message-ID: <4C50C02E.5070007@oracle.com> Date: Wed, 28 Jul 2010 19:41:34 -0400 From: "Roger A. Faulkner" User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.9.2.4) Gecko/20100705 Lightning/1.0b2 Thunderbird/3.1 MIME-Version: 1.0 To: psarc-ext@sac.sfbay.sun.com CC: Scott Michael , jeff.bonwick@oracle.com, brendan.doyle@oracle.com Subject: GNU/Linux/BSD compatibility functions [PSARC/2010/299 FastTrack timeout, 08/04/2010] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4C50C04F.0230:SCFMA4539814,ss=1,fgs=0 Status: RO Content-Length: 6949 I am sponsoring this fast-track case for myself. Timeout is Wednesday, 08/04/2010 1. Introduction This case adds 28 new functions to the C library, all in the name of compatibility with GNU/Linux and FreeBSD. The commitment level of these interfaces is Committed. The release binding is "minor" so they can be implemented in Solaris Next/11. If anyone wants to back-port any of these functions to Solaris 10, they should file a separate ARC case. 2. Discussion 2. Discussion Over the last few years. there have been several bug reports (RFEs) filed requesting such functions for Solaris: 6275498 Provide string compare functions wcscasecmp,wcsncasecmp in solaris like linux 6421095 Solaris should provide strcasestr 6793969 RFE: Add|stpcpy|to libc 6960818 add get_nprocs(), getline(), strdupa(), strndup() to libc This case goes beyond the bare requests in these bug reports and provides generally-useful interfaces that are documented in GNU/Linux/BSD manual pages. In addition to existing in GNU/Linux/BSD manual pages, many of these functions are also specified in the new POSIX standard: IEEE Std 1003.1(TM)-2008 The Open Group Technical Standard Base Specifications, Issue 7 hereinafter referred to as SUSv4. 3. Details Unless stated otherwise, all of the following functions are new functions being added to the C library. Many of these functions are specified in the new POSIX standard: IEEE Std 1003.1(TM)-2008 The Open Group Technical Standard Base Specifications, Issue 7 hereinafter referred to as SUSv4. Others are specified in GNU/Linux man pages or in OpenBSD man pages, indicated on a case-by-case basis. =========================================================== #include char *strndup(const char *, size_t); char *stpcpy(char *restrict, const char *restrict); char *stpncpy(char *restrict, const char *restrict, size_t); char *strchrnul(const char *, int); char *strdupa(const char *); char *strndupa(const char *, size_t); char *strnstr(const char *s1, const char *s2, size_t n); char *strcasestr(const char *s1, const char *s2); The strndup(), stpcpy() and stpncpy() functions are specified in SUSv4. The strchrnul(). strdupa() and strndupa() functions are GNU/Linux extensions. The strnstr() and strcasestr() are FreeBSD extensions. =========================================================== These two existing functions, previously ASCII-only, become locale-dependent, as specified in SUSv4: #include int strcasecmp(const char *s1, const char *s2) int strncasecmp(const char *s1, const char *s2, size_t n) =========================================================== #include int ppoll(struct pollfd *restrict fds, nfds_t nfds, const struct timespec *restrict timeout, const sigset_t *restrict sigmask); The ppoll() function is a GNU/Linux extension. =========================================================== #include ssize_t getdelim(char **restrict, size_t *restrict, int, FILE *restrict); ssize_t getline(char **restrict, size_t *restrict, FILE *restrict); The getdelim() and getline() functions are specified in SUSv4. =========================================================== #include void *memmem(const void *, size_t, const void *, size_t); The memmem() function is a GNU/Linux and FreeBSD extension. =========================================================== #include int fcloseall(void); The fcloseall() function is a GNU/Linux and FreeBSD extension. =========================================================== #include int clearenv(void); The clearenv() function is a GNU/Linux extension. =========================================================== The semantics of the following existing function have changed a bit, as specified in SUSv4: #include char *realpath(const char *file_name, char *resolved_name); In particular, the semantics for 'resolved_name' being passed in as a NULL pointer have changed. Previously, this resulted in failure with errno == EINVAL. Now, realpath() allocates a buffer using malloc(): If resolved_name is a null pointer, the generated pathname shall be stored as a null-terminated string in a buffer allocated as if by a call to malloc(). =========================================================== #include char *canonicalize_file_name(const char *path); The canonicalize_file_name() function is a GNU/Linux extension. It is equivalent to realpath(path, NULL) (see above). =========================================================== #include int ffsl(long); int ffsll(long long); int fls(int); int flsl(long); int flsll(long long); These functions are FreeBSD extensions. =========================================================== #include wchar_t *wcsdup(const wchar_t *); size_t wcsnlen(const wchar_t *, size_t); wchar_t *wcpcpy(wchar_t *restrict, const wchar_t *restrict); wchar_t *wcpncpy(wchar_t *restrict, const wchar_t *restrict, size_t); int wcscasecmp(const wchar_t *, const wchar_t *); int wcsncasecmp(const wchar_t *, const wchar_t *, size_t); These functions are specified in SUSv4. =========================================================== int get_nprocs(void); int get_nprocs_conf(void); The get_nprocs() and get_nprocs_conf() are GNU/Linux extensions equivalent, respectively, to: sysconf(_SC_NPROCESSORS_ONLN); sysconf(_SC_NPROCESSORS_CONF); =========================================================== Since SUSv4 changes are being made to the system, the following definitions are being added to , as specified in SUSv4, because these features already exist: _POSIX_THREAD_ROBUST_PRIO_INHERIT Implementation supports the Robust Mutex Priority Inheritance option. _POSIX_THREAD_ROBUST_PRIO_PROTECT Implementation supports the Robust Mutex Priority Protection option. _SC_THREAD_ROBUST_PRIO_INHERIT _SC_THREAD_ROBUST_PRIO_PROTECT =========================================================== 4. Manual pages. New and modified manual pages will be created from the SUSv4 POSIX specifications where the relevant functions are defined therein, and from GNU/Linux and FreeBSD manual pages otherwise. From garrett@damore.org Wed Jul 28 16:59:37 2010 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o6SNxba9005667 for ; Wed, 28 Jul 2010 16:59:37 -0700 (PDT) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o6SNxb91020194 for ; Wed, 28 Jul 2010 16:59:37 -0700 (PDT) Received: from relay41i.sun.com ([192.5.209.70]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o6SNxVBW010397 for ; Wed, 28 Jul 2010 23:59:31 GMT Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay41i.sun.com with ESMTP id BT-MMP-361250 for psarc-ext@sac.sfbay.sun.com; Wed, 28 Jul 2010 23:59:31 Z Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mms49es.mms.us.syntegra.com with ESMTP id BT-MMP-50181969 for psarc-ext@sac.sfbay.sun.com; Wed, 28 Jul 2010 23:59:30 Z Received: from oproxy1-pub.bluehost.com ([66.147.249.253] [66.147.249.253]) by relay4i.sun.com id BT-MMP-17262075 for psarc-ext@sac.sfbay.sun.com; Wed, 28 Jul 2010 23:59:30 Z Received: (qmail 8091 invoked by uid 0); 28 Jul 2010 23:01:00 -0000 Received: from unknown (HELO box374.bluehost.com) (69.89.31.174) by oproxy1.bluehost.com.bluehost.com with SMTP; 28 Jul 2010 23:01:00 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=damore.org; h=Received:Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date:Message-ID:Mime-Version:X-Mailer:Content-Transfer-Encoding:X-Identified-User; b=lTzlPdX28hcpm54ZswTr+auvQQSJwYamrPt5ivLxumGzDAHLVsaZRPwo5z614HvXDajehT5cQ1vjvW6Du+u+T8DF0FPbLIQpYC8fdLUuoNA/RtwuFfpCwkd1GSAqVYgX; Received: from cpe-75-82-74-133.socal.res.rr.com ([75.82.74.133] helo=[192.168.251.102]) by box374.bluehost.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OeGX3-0001kU-Hu; Wed, 28 Jul 2010 17:59:29 -0600 Subject: Re: GNU/Linux/BSD compatibility functions [PSARC/2010/299 FastTrack timeout, 08/04/2010] From: "Garrett D'Amore" To: "Roger A. Faulkner" Cc: psarc-ext@sac.sfbay.sun.com, brendan.doyle@oracle.com, jeff.bonwick@oracle.com, Scott Michael In-Reply-To: <4C50C02E.5070007@oracle.com> References: <4C50C02E.5070007@oracle.com> Date: Wed, 28 Jul 2010 16:59:33 -0700 Message-ID: <1280361573.6326.96.camel@velocity> X-Brightmail-Tracker: AAAAAA== X-Mailer: Evolution 2.28.3 X-Identified-User: {2225:box374.bluehost.com:damoreor:damore.org} {sentby:smtp auth 75.82.74.133 authed with garrett+damore.org} X-Antispam: No, score=-1.1/5.0, scanned in 0.302sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Status: RO Content-Length: 7592 +1 These all look good! - Garrett On Wed, 2010-07-28 at 19:41 -0400, Roger A. Faulkner wrote: > I am sponsoring this fast-track case for myself. > Timeout is Wednesday, 08/04/2010 > > 1. Introduction > > This case adds 28 new functions to the C library, all in the > name of compatibility with GNU/Linux and FreeBSD. > > The commitment level of these interfaces is Committed. > > The release binding is "minor" so they can be implemented > in Solaris Next/11. If anyone wants to back-port any of > these functions to Solaris 10, they should file a separate > ARC case. > > 2. Discussion > > 2. Discussion > > Over the last few years. there have been several bug reports > (RFEs) filed requesting such functions for Solaris: > > 6275498 Provide string compare functions wcscasecmp,wcsncasecmp > in solaris like linux > 6421095 Solaris should provide strcasestr > 6793969 RFE: Add|stpcpy|to libc > 6960818 add get_nprocs(), getline(), strdupa(), strndup() to libc > > This case goes beyond the bare requests in these bug reports > and provides generally-useful interfaces that are documented > in GNU/Linux/BSD manual pages. > > In addition to existing in GNU/Linux/BSD manual pages, many > of these functions are also specified in the new POSIX standard: > IEEE Std 1003.1(TM)-2008 > The Open Group Technical Standard > Base Specifications, Issue 7 > hereinafter referred to as SUSv4. > > 3. Details > > Unless stated otherwise, all of the following functions > are new functions being added to the C library. > > Many of these functions are specified in the new POSIX standard: > IEEE Std 1003.1(TM)-2008 > The Open Group Technical Standard > Base Specifications, Issue 7 > hereinafter referred to as SUSv4. > > Others are specified in GNU/Linux man pages or in > OpenBSD man pages, indicated on a case-by-case basis. > > =========================================================== > > #include > > char *strndup(const char *, size_t); > char *stpcpy(char *restrict, const char *restrict); > char *stpncpy(char *restrict, const char *restrict, size_t); > > char *strchrnul(const char *, int); > char *strdupa(const char *); > char *strndupa(const char *, size_t); > > char *strnstr(const char *s1, const char *s2, size_t n); > char *strcasestr(const char *s1, const char *s2); > > The strndup(), stpcpy() and stpncpy() functions are specified in SUSv4. > The strchrnul(). strdupa() and strndupa() functions are GNU/Linux > extensions. > The strnstr() and strcasestr() are FreeBSD extensions. > > =========================================================== > > These two existing functions, previously ASCII-only, > become locale-dependent, as specified in SUSv4: > > #include > > int strcasecmp(const char *s1, const char *s2) > int strncasecmp(const char *s1, const char *s2, size_t n) > > =========================================================== > > #include > > int ppoll(struct pollfd *restrict fds, nfds_t nfds, > const struct timespec *restrict timeout, > const sigset_t *restrict sigmask); > > The ppoll() function is a GNU/Linux extension. > > =========================================================== > > #include > > ssize_t getdelim(char **restrict, size_t *restrict, > int, FILE *restrict); > ssize_t getline(char **restrict, size_t *restrict, > FILE *restrict); > > The getdelim() and getline() functions are specified in SUSv4. > > =========================================================== > > #include > > void *memmem(const void *, size_t, const void *, size_t); > > The memmem() function is a GNU/Linux and FreeBSD extension. > > =========================================================== > > #include > > int fcloseall(void); > > The fcloseall() function is a GNU/Linux and FreeBSD extension. > > =========================================================== > > #include > > int clearenv(void); > > The clearenv() function is a GNU/Linux extension. > > =========================================================== > > The semantics of the following existing function have > changed a bit, as specified in SUSv4: > > #include > > char *realpath(const char *file_name, char *resolved_name); > > In particular, the semantics for 'resolved_name' being > passed in as a NULL pointer have changed. > Previously, this resulted in failure with errno == EINVAL. > Now, realpath() allocates a buffer using malloc(): > If resolved_name is a null pointer, the generated pathname > shall be stored as a null-terminated string in a buffer > allocated as if by a call to malloc(). > > =========================================================== > > #include > > char *canonicalize_file_name(const char *path); > > The canonicalize_file_name() function is a GNU/Linux extension. > It is equivalent to realpath(path, NULL) (see above). > > =========================================================== > > #include > > int ffsl(long); > int ffsll(long long); > int fls(int); > int flsl(long); > int flsll(long long); > > These functions are FreeBSD extensions. > > =========================================================== > > #include > > wchar_t *wcsdup(const wchar_t *); > size_t wcsnlen(const wchar_t *, size_t); > wchar_t *wcpcpy(wchar_t *restrict, const wchar_t *restrict); > wchar_t *wcpncpy(wchar_t *restrict, const wchar_t *restrict, size_t); > int wcscasecmp(const wchar_t *, const wchar_t *); > int wcsncasecmp(const wchar_t *, const wchar_t *, size_t); > > These functions are specified in SUSv4. > > =========================================================== > > int get_nprocs(void); > int get_nprocs_conf(void); > > The get_nprocs() and get_nprocs_conf() are GNU/Linux extensions > equivalent, respectively, to: > sysconf(_SC_NPROCESSORS_ONLN); > sysconf(_SC_NPROCESSORS_CONF); > > =========================================================== > > Since SUSv4 changes are being made to the system, > the following definitions are being added to , > as specified in SUSv4, because these features already exist: > > _POSIX_THREAD_ROBUST_PRIO_INHERIT > Implementation supports the Robust Mutex Priority Inheritance > option. > > _POSIX_THREAD_ROBUST_PRIO_PROTECT > Implementation supports the Robust Mutex Priority Protection > option. > > _SC_THREAD_ROBUST_PRIO_INHERIT > _SC_THREAD_ROBUST_PRIO_PROTECT > > =========================================================== > > 4. Manual pages. > > New and modified manual pages will be created from the > SUSv4 POSIX specifications where the relevant functions > are defined therein, and from GNU/Linux and FreeBSD > manual pages otherwise. > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org From Darren.Moffat@Oracle.COM Wed Jul 28 22:42:41 2010 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o6T5gfbF011456 for ; Wed, 28 Jul 2010 22:42:41 -0700 (PDT) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o6T5gflG002047 for ; Wed, 28 Jul 2010 22:42:41 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o6T5gfFd008216 for ; Thu, 29 Jul 2010 05:42:41 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6T3KCks022686 for ; Thu, 29 Jul 2010 05:42:40 GMT Received: from abhmt003.oracle.com by acsmt353.oracle.com with ESMTP id 466635601280382124; Wed, 28 Jul 2010 22:42:04 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 28 Jul 2010 22:42:03 -0700 Message-ID: <4C5114A8.9040300@Oracle.COM> Date: Thu, 29 Jul 2010 06:42:00 +0100 From: Darren J Moffat Organization: Oracle Solaris Security User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Lightning/1.0b1 OracleBeehiveExtension/1.0.0.0pre3 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Roger A. Faulkner" CC: psarc-ext@sac.sfbay.sun.com, Scott Michael , jeff.bonwick@Oracle.COM, brendan.doyle@Oracle.COM Subject: Re: GNU/Linux/BSD compatibility functions [PSARC/2010/299 FastTrack timeout, 08/04/2010] References: <4C50C02E.5070007@oracle.com> In-Reply-To: <4C50C02E.5070007@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4C5114D1.000D:SCFMA4539814,ss=1,fgs=0 Status: RO Content-Length: 183 A great set of additions none of which seem controversial to me and many of which I've lacked when compiling random bits of FOSS, so it gets my +1 as specified. -- Darren J Moffat From joerg.schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Thu Jul 29 05:26:49 2010 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o6TCQm4O014498 for ; Thu, 29 Jul 2010 05:26:49 -0700 (PDT) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o6TCQmom018336 for ; Thu, 29 Jul 2010 05:26:48 -0700 (PDT) Received: from relay44i.sun.com ([192.5.209.118]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o6TCQlhD019384 for ; Thu, 29 Jul 2010 12:26:47 GMT Received: from mmp41es.mmp.us.syntegra.com ([160.41.221.10] [160.41.221.10]) by relay44i.sun.com with ESMTP id BT-MMP-54462 for psarc-ext@sac.sfbay.sun.com; Thu, 29 Jul 2010 12:26:47 Z Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mmp41es.mmp.us.syntegra.com with ESMTP id BT-MMP-51198506 for psarc-ext@sac.sfbay.sun.com; Thu, 29 Jul 2010 12:26:44 Z Received: from relay04-haj2.antispameurope.com ([83.246.65.54] [83.246.65.54]) by relay4i.sun.com with ESMTP id BT-MMP-2229427 for psarc-ext@sac.sfbay.sun.com; Thu, 29 Jul 2010 12:26:43 Z Received: by relay04-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 41D8A2F802C; Thu, 29 Jul 2010 14:26:42 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay04-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 53F8E5EC3B7; Thu, 29 Jul 2010 14:26:40 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id o6TCQejP003834; Thu, 29 Jul 2010 14:26:40 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Jul 2010 14:26:39 +0200 Date: Thu, 29 Jul 2010 14:26:36 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) To: roger.faulkner@oracle.com, psarc-ext@sac.sfbay.sun.com Cc: scott.michael@oracle.com, jeff.bonwick@oracle.com, brendan.doyle@oracle.com Subject: Re: GNU/Linux/BSD compatibility functions [PSARC/2010/299 FastTrack timeout, 08/04/2010] Message-ID: <4c51737c.0T95qnn9oJQonEPN%Joerg.Schilling@fokus.fraunhofer.de> References: <4C50C02E.5070007@oracle.com> In-Reply-To: <4C50C02E.5070007@oracle.com> User-Agent: nail 11.22 3/20/05 X-Brightmail-Tracker: AAAAAA== X-OriginalArrivalTime: 29 Jul 2010 12:26:39.0948 (UTC) FILETIME=[4B9D50C0:01CB2F19] X-Antispam: No, score=0.0/5.0, scanned in 2.901sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: joerg.schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Status: RO Content-Length: 1058 "Roger A. Faulkner" wrote: > =========================================================== > > #include > > ssize_t getdelim(char **restrict, size_t *restrict, > int, FILE *restrict); > ssize_t getline(char **restrict, size_t *restrict, > FILE *restrict); > > The getdelim() and getline() functions are specified in SUSv4. This getline() is in conflict with a basic POSIX rule: POSIX does not define interfaces that are inconflict with existing public interfaces on UNIX systems. There is a public getline() function defined aprox. 1980-1982: ssize_t fgetline __PR((FILE *, char *, size_t)); and there are local functions on Solaris that are called getline()... Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From roger.faulkner@ORACLE.COM Thu Jul 29 05:53:16 2010 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o6TCrG24014610 for ; Thu, 29 Jul 2010 05:53:16 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o6TCrGlx007517 for ; Thu, 29 Jul 2010 05:53:16 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o6TCrGsX017860 for ; Thu, 29 Jul 2010 12:53:16 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6TB0IT4016517; Thu, 29 Jul 2010 12:53:12 GMT Received: from abhmt015.oracle.com by acsmt355.oracle.com with ESMTP id 467708661280407977; Thu, 29 Jul 2010 05:52:57 -0700 Received: from [10.7.251.247] (/10.7.251.247) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Jul 2010 05:52:57 -0700 Message-ID: <4C5179A3.4010309@oracle.com> Date: Thu, 29 Jul 2010 08:52:51 -0400 From: "Roger A. Faulkner" User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.9.2.4) Gecko/20100705 Lightning/1.0b2 Thunderbird/3.1 MIME-Version: 1.0 To: Joerg.Schilling@fokus.fraunhofer.de CC: psarc-ext@sac.sfbay.sun.com, scott.michael@ORACLE.COM, jeff.bonwick@ORACLE.COM, brendan.doyle@ORACLE.COM Subject: Re: GNU/Linux/BSD compatibility functions [PSARC/2010/299 FastTrack timeout, 08/04/2010] References: <4C50C02E.5070007@oracle.com> <4c51737c.0T95qnn9oJQonEPN%Joerg.Schilling@fokus.fraunhofer.de> In-Reply-To: <4c51737c.0T95qnn9oJQonEPN%Joerg.Schilling@fokus.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4C5179B9.02AD:SCFMA4539814,ss=1,fgs=0 Status: RO Content-Length: 1661 On 07/29/10 08:26, Joerg.Schilling@fokus.fraunhofer.de wrote: > "Roger A. Faulkner" wrote: > >> =========================================================== >> >> #include >> >> ssize_t getdelim(char **restrict, size_t *restrict, >> int, FILE *restrict); >> ssize_t getline(char **restrict, size_t *restrict, >> FILE *restrict); >> >> The getdelim() and getline() functions are specified in SUSv4. > This getline() is in conflict with a basic POSIX rule: > > POSIX does not define interfaces that are inconflict with existing > public interfaces on UNIX systems. That an issue for the standards body. I'm just following the SUSv4 specification, as well as getline() as defined by recent versions of GNU/Linux, which has the same function signature. FWIW, I agree that 'getline' was an unfortunate choice of a name for this interface by the standards body, since 'getline' is such a commonly-used name. > There is a public getline() function defined aprox. 1980-1982: > > ssize_t fgetline __PR((FILE *, char *, size_t)); > > and there are local functions on Solaris that are called getline()... Yes, 32 of them, none of them public interfaces. Plus there are about 200 references to them. I changed all of them to a different name, which is what others will have to do when compiling code that has instances of 'getline' in it once they install a system with this change in and libc. There will be a release note about this when the project is integrated. There will be no problem with running such apps until they need to be recompiled. Roger From garrett@damore.org Thu Jul 29 10:12:43 2010 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o6THChVK018578 for ; Thu, 29 Jul 2010 10:12:43 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o6THCg3U004676 for ; Thu, 29 Jul 2010 10:12:43 -0700 (PDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o6TGmU4p003005 for ; Thu, 29 Jul 2010 17:12:42 GMT Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay13i.sun.com with ESMTP id BT-MMP-204622 for psarc-ext@sac.sfbay.sun.com; Thu, 29 Jul 2010 17:12:42 Z Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-257857 for psarc-ext@sac.sfbay.sun.com; Thu, 29 Jul 2010 17:12:41 Z Received: from oproxy2-pub.bluehost.com ([67.222.39.60] [67.222.39.60]) by relay1i.sun.com id BT-MMP-26886005 for psarc-ext@sac.sfbay.sun.com; Thu, 29 Jul 2010 17:12:41 Z Received: (qmail 8827 invoked by uid 0); 29 Jul 2010 17:12:41 -0000 Received: from unknown (HELO box374.bluehost.com) (69.89.31.174) by oproxy2.bluehost.com with SMTP; 29 Jul 2010 17:12:41 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=damore.org; h=Received:Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date:Message-ID:Mime-Version:X-Mailer:Content-Transfer-Encoding:X-Identified-User; b=gLqmalndGmMaShX0Zrzi2cXnDOLuNOuzAilUeGNCXg/pLRQzoHHC6hedtcYILJMHKzJCphXbVIpZPvZ+mfH2PuqyfSHKwZgRZGorL907dORnHwJKPy9Qz8dKqBzeQlJ+; Received: from cpe-75-82-74-133.socal.res.rr.com ([75.82.74.133] helo=[192.168.251.102]) by box374.bluehost.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OeWeu-0005yz-Gr; Thu, 29 Jul 2010 11:12:40 -0600 Subject: Re: GNU/Linux/BSD compatibility functions [PSARC/2010/299 FastTrack timeout, 08/04/2010] From: "Garrett D'Amore" To: "Roger A. Faulkner" Cc: Joerg.Schilling@fokus.fraunhofer.de, brendan.doyle@ORACLE.COM, jeff.bonwick@ORACLE.COM, psarc-ext@sac.sfbay.sun.com, scott.michael@ORACLE.COM In-Reply-To: <4C5179A3.4010309@oracle.com> References: <4C50C02E.5070007@oracle.com> <4c51737c.0T95qnn9oJQonEPN%Joerg.Schilling@fokus.fraunhofer.de> <4C5179A3.4010309@oracle.com> Date: Thu, 29 Jul 2010 10:12:46 -0700 Message-ID: <1280423566.6326.302.camel@velocity> X-Brightmail-Tracker: AAAAAA== X-Mailer: Evolution 2.28.3 X-Identified-User: {2225:box374.bluehost.com:damoreor:damore.org} {sentby:smtp auth 75.82.74.133 authed with garrett+damore.org} X-Antispam: No, score=-0.2/5.0, scanned in 0.309sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Status: RO Content-Length: 2645 On Thu, 2010-07-29 at 08:52 -0400, Roger A. Faulkner wrote: > On 07/29/10 08:26, Joerg.Schilling@fokus.fraunhofer.de wrote: > > "Roger A. Faulkner" wrote: > > > >> =========================================================== > >> > >> #include > >> > >> ssize_t getdelim(char **restrict, size_t *restrict, > >> int, FILE *restrict); > >> ssize_t getline(char **restrict, size_t *restrict, > >> FILE *restrict); > >> > >> The getdelim() and getline() functions are specified in SUSv4. > > This getline() is in conflict with a basic POSIX rule: > > > > POSIX does not define interfaces that are inconflict with existing > > public interfaces on UNIX systems. > > That an issue for the standards body. > I'm just following the SUSv4 specification, as well as getline() > as defined by recent versions of GNU/Linux, which has the > same function signature. But this name won't be in the namespace unless __EXTENSIONS__ or whatever it is is defined, right? So its not a POSIX problem. > > FWIW, I agree that 'getline' was an unfortunate choice of a name > for this interface by the standards body, since 'getline' is such > a commonly-used name. > > > There is a public getline() function defined aprox. 1980-1982: > > > > ssize_t fgetline __PR((FILE *, char *, size_t)); > > > > and there are local functions on Solaris that are called getline()... > > Yes, 32 of them, none of them public interfaces. > Plus there are about 200 references to them. > I changed all of them to a different name, which > is what others will have to do when compiling code > that has instances of 'getline' in it once they install > a system with this change in and libc. > > There will be a release note about this > when the project is integrated. > > There will be no problem with running such apps > until they need to be recompiled. Again, only if __EXTENSIONS__ is defined. Which means ON itself, but not sure what else. It would be *good* if some of those 200 could just scrap local implementations and use the new libc version, provided of course that the semantics are the same as the libc version and its not just a name conflict for totally irrelevant functionality. The fact that these names would collide for Linux suggests to me this is not likely to be a major problem in 3rd party software. Frankly at this point (sadly) most people start on Linux and then only port to Solaris later. - Garrett > > Roger > > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org From Gordon.Ross@oracle.com Thu Jul 29 10:17:55 2010 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o6THHtVE018635 for ; Thu, 29 Jul 2010 10:17:55 -0700 (PDT) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o6THHt18018131 for ; Thu, 29 Jul 2010 10:17:55 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o6THHoad028304 for ; Thu, 29 Jul 2010 17:17:50 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6T3YqZZ017481 for ; Thu, 29 Jul 2010 17:17:49 GMT Received: from abhmt009.oracle.com by acsmt355.oracle.com with ESMTP id 449462561280423868; Thu, 29 Jul 2010 10:17:48 -0700 Received: from [129.153.21.195] (/129.153.21.195) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Jul 2010 10:17:48 -0700 Subject: Re: GNU/Linux/BSD compatibility functions [PSARC/2010/299 FastTrack timeout, 08/04/2010] From: Gordon Ross To: "Roger A. Faulkner" Cc: psarc-ext@sac.sfbay.sun.com, Scott Michael , jeff.bonwick@oracle.com, brendan.doyle@oracle.com In-Reply-To: <4C50C02E.5070007@oracle.com> References: <4C50C02E.5070007@oracle.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 29 Jul 2010 10:16:27 -0700 Message-ID: <1280423787.1236.7.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.30.1.2 Content-Transfer-Encoding: 7bit X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4C51B7BD.0267:SCFMA4539814,ss=1,fgs=0 Status: RO Content-Length: 270 This is _so_ overdue. Thanks for working on it. Would you consider adding this well-known BSD symbol too? extern char * __progname; Or would you consider that out of scope? Here's a CR for it: 6735446 Want a __progname symbol for BSD-style source compatibility From roger.faulkner@oracle.com Thu Jul 29 10:39:12 2010 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o6THdC8x018957 for ; Thu, 29 Jul 2010 10:39:12 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o6THdCAS025037 for ; Thu, 29 Jul 2010 10:39:12 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o6THdBuu002623 for ; Thu, 29 Jul 2010 17:39:11 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6THd8qj008373; Thu, 29 Jul 2010 17:39:08 GMT Received: from abhmt016.oracle.com by acsmt354.oracle.com with ESMTP id 468681511280425092; Thu, 29 Jul 2010 10:38:12 -0700 Received: from [10.7.251.247] (/10.7.251.247) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Jul 2010 10:38:11 -0700 Message-ID: <4C51BC80.9070806@oracle.com> Date: Thu, 29 Jul 2010 13:38:08 -0400 From: "Roger A. Faulkner" User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.9.2.4) Gecko/20100705 Lightning/1.0b2 Thunderbird/3.1 MIME-Version: 1.0 To: "Garrett D'Amore" CC: Joerg.Schilling@fokus.fraunhofer.de, brendan.doyle@oracle.com, jeff.bonwick@oracle.com, psarc-ext@sac.sfbay.sun.com, scott.michael@oracle.com Subject: Re: GNU/Linux/BSD compatibility functions [PSARC/2010/299 FastTrack timeout, 08/04/2010] References: <4C50C02E.5070007@oracle.com> <4c51737c.0T95qnn9oJQonEPN%Joerg.Schilling@fokus.fraunhofer.de> <4C5179A3.4010309@oracle.com> <1280423566.6326.302.camel@velocity> In-Reply-To: <1280423566.6326.302.camel@velocity> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4C51BCBD.0147:SCFMA4539814,ss=1,fgs=0 Status: RO Content-Length: 3730 On 07/29/10 13:12, Garrett D'Amore wrote: > On Thu, 2010-07-29 at 08:52 -0400, Roger A. Faulkner wrote: >> On 07/29/10 08:26, Joerg.Schilling@fokus.fraunhofer.de wrote: >>> "Roger A. Faulkner" wrote: >>> >>>> =========================================================== >>>> >>>> #include >>>> >>>> ssize_t getdelim(char **restrict, size_t *restrict, >>>> int, FILE *restrict); >>>> ssize_t getline(char **restrict, size_t *restrict, >>>> FILE *restrict); >>>> >>>> The getdelim() and getline() functions are specified in SUSv4. >>> This getline() is in conflict with a basic POSIX rule: >>> >>> POSIX does not define interfaces that are inconflict with existing >>> public interfaces on UNIX systems. >> That an issue for the standards body. >> I'm just following the SUSv4 specification, as well as getline() >> as defined by recent versions of GNU/Linux, which has the >> same function signature. > But this name won't be in the namespace unless __EXTENSIONS__ or > whatever it is is defined, right? So its not a POSIX problem. The namespace guards are: #if defined(__EXTENSIONS__) || \ (!defined(_STRICT_STDC) && !defined(__XOPEN_OR_POSIX)) So the names from the header file are visible if: - You define __EXTENSIONS__ - You don't request strict standard C or a particular standards conformance option (like _XPG6). I believe most applications fall into the second category. Any of them that include and also have a local function named 'getline' will be impacted. When they recompile, they will have to rename their local function (unless [unlikely] it is really the same as the library's getline() in which case they should just delete their local version). Previously-compiled versions of the application will continue to work as always. This is only a potential recompile problem. (And this is the case whenever we add any new public function to libc and the header files. It's just that 'getline' seems to be a popular function name. And everyone includes ) >> FWIW, I agree that 'getline' was an unfortunate choice of a name >> for this interface by the standards body, since 'getline' is such >> a commonly-used name. >> >>> There is a public getline() function defined aprox. 1980-1982: >>> >>> ssize_t fgetline __PR((FILE *, char *, size_t)); >>> >>> and there are local functions on Solaris that are called getline()... >> Yes, 32 of them, none of them public interfaces. >> Plus there are about 200 references to them. >> I changed all of them to a different name, which >> is what others will have to do when compiling code >> that has instances of 'getline' in it once they install >> a system with this change in and libc. >> >> There will be a release note about this >> when the project is integrated. >> >> There will be no problem with running such apps >> until they need to be recompiled. > Again, only if __EXTENSIONS__ is defined. Which means ON itself, but > not sure what else. See above. > It would be *good* if some of those 200 could just scrap local > implementations and use the new libc version, provided of course that > the semantics are the same as the libc version and its not just a name > conflict for totally irrelevant functionality. All of these 200 instances are just name conflicts. The local getline() functions are quite different from the libc version. > The fact that these names would collide for Linux suggests to me this is > not likely to be a major problem in 3rd party software. Frankly at this > point (sadly) most people start on Linux and then only port to Solaris > later. > > - Garrett Roger From roger.faulkner@oracle.com Mon Aug 2 12:05:49 2010 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o72J5nEP019778 for ; Mon, 2 Aug 2010 12:05:49 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o72J5nM7003827 for ; Mon, 2 Aug 2010 12:05:49 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o72J5mLw026443 for ; Mon, 2 Aug 2010 19:05:49 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o72Ir099006202 for ; Mon, 2 Aug 2010 19:05:42 GMT Received: from abhmt019.oracle.com by acsmt354.oracle.com with ESMTP id 477666441280775888; Mon, 02 Aug 2010 12:04:48 -0700 Received: from [10.7.251.247] (/10.7.251.247) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 02 Aug 2010 12:04:47 -0700 Message-ID: <4C5716CB.1020209@oracle.com> Date: Mon, 02 Aug 2010 15:04:43 -0400 From: "Roger A. Faulkner" User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.9.2.4) Gecko/20100705 Lightning/1.0b2 Thunderbird/3.1 MIME-Version: 1.0 To: Gordon Ross CC: psarc-ext@sac.sfbay.sun.com, Scott Michael , jeff.bonwick@oracle.com, brendan.doyle@oracle.com Subject: Re: GNU/Linux/BSD compatibility functions [PSARC/2010/299 FastTrack timeout, 08/04/2010] References: <4C50C02E.5070007@oracle.com> <1280423787.1236.7.camel@localhost> In-Reply-To: <1280423787.1236.7.camel@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4C57170B.02A1:SCFMA4539814,ss=1,fgs=0 Status: RO Content-Length: 953 On 07/29/10 13:16, Gordon Ross wrote: > This is _so_ overdue. Thanks for working on it. > > Would you consider adding this well-known BSD symbol too? > extern char * __progname; > > Or would you consider that out of scope? Here's a CR for it: > 6735446 Want a __progname symbol for BSD-style source compatibility Not out-of-scope at all. Consider the __progname global variable added to this case. Also, these functions from FreeBSD are added to the case: #include const char * getprogname(void); void setprogname(const char *progname); Following FreeBSD's lead, the __progname variable, even though it will exist, will not be declared in any header file, and it will be versioned as SUNWprivate_1.1 Applications that want to use it will have to declare it themselves. FreeBSD encourages the use of getprogname() rather than directly referencing __progname. Solaris will do the same. Roger From roger.faulkner@oracle.com Mon Aug 2 18:21:05 2010 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o731L57E027511 for ; Mon, 2 Aug 2010 18:21:05 -0700 (PDT) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o731L5SZ023288 for ; Mon, 2 Aug 2010 18:21:05 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o731Kx4j017135 for ; Tue, 3 Aug 2010 01:20:59 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o72Kfmkt026648 for ; Tue, 3 Aug 2010 01:20:58 GMT Received: from abhmt020.oracle.com by acsmt354.oracle.com with ESMTP id 459692211280798381; Mon, 02 Aug 2010 18:19:41 -0700 Received: from [10.7.251.247] (/10.7.251.247) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 02 Aug 2010 18:19:40 -0700 Message-ID: <4C576EAA.4040101@oracle.com> Date: Mon, 02 Aug 2010 21:19:38 -0400 From: "Roger A. Faulkner" User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.9.2.4) Gecko/20100705 Lightning/1.0b2 Thunderbird/3.1 MIME-Version: 1.0 To: Gordon Ross CC: psarc-ext@sac.sfbay.sun.com, Scott Michael , jeff.bonwick@oracle.com, brendan.doyle@oracle.com Subject: Re: GNU/Linux/BSD compatibility functions [PSARC/2010/299 FastTrack timeout, 08/04/2010] References: <4C50C02E.5070007@oracle.com> <1280423787.1236.7.camel@localhost> <4C5716CB.1020209@oracle.com> In-Reply-To: <4C5716CB.1020209@oracle.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4C576EFB.0106:SCFMA4539814,ss=1,fgs=0 Status: RO Content-Length: 8015 As a result of suggestions made in the email for this case, I am sending this revised, final version of the proposal (with additional bugids included and with the description of getprogname(), setprogname() and __progname included): =================================================================== 1. Introduction This case adds 30 new functions and one global variable to the C library, all in the name of compatibility with GNU/Linux and FreeBSD. The commitment level of the functional interfaces is Committed. The release binding is "minor" so they can be implemented in Solaris Next/11. If anyone wants to back-port any of these functions to Solaris 10, they should file a separate ARC case. 2. Discussion Over the last few years. there have been several bug reports (RFEs) filed requesting such functions for Solaris: 6960818 add get_nprocs(), getline(), strdupa(), strndup() to libc 6901783 strndup would be nice 6824404 libc should provide ffsl() & ffsll() 6793969 RFE: Add|stpcpy|to libc 6735446 Want a __progname symbol for BSD-style source compatibility 6421095 Solaris should provide strcasestr 6275498 Provide string compare functions wcscasecmp,wcsncasecmp in solaris like linux This case goes beyond the bare requests in these bug reports and provides generally-useful interfaces that are documented in GNU/Linux/BSD manual pages. In addition to existing in GNU/Linux/BSD manual pages, many of these functions are also specified in the new POSIX standard: IEEE Std 1003.1(TM)-2008 The Open Group Technical Standard Base Specifications, Issue 7 hereinafter referred to as SUSv4. 3. Details Unless stated otherwise, all of the following functions are new functions being added to the C library. Many of these functions are specified in the new POSIX standard: IEEE Std 1003.1(TM)-2008 The Open Group Technical Standard Base Specifications, Issue 7 hereinafter referred to as SUSv4. Others are specified in GNU/Linux man pages or in OpenBSD man pages, indicated on a case-by-case basis. =========================================================== #include char *strndup(const char *, size_t); char *stpcpy(char *restrict, const char *restrict); char *stpncpy(char *restrict, const char *restrict, size_t); char *strchrnul(const char *, int); char *strdupa(const char *); char *strndupa(const char *, size_t); char *strnstr(const char *s1, const char *s2, size_t n); char *strcasestr(const char *s1, const char *s2); The strndup(), stpcpy() and stpncpy() functions are specified in SUSv4. The strchrnul(). strdupa() and strndupa() functions are GNU/Linux extensions. The strnstr() and strcasestr() are FreeBSD extensions. =========================================================== These two existing functions, previously ASCII-only, become locale-dependent, as specified in SUSv4: #include int strcasecmp(const char *s1, const char *s2) int strncasecmp(const char *s1, const char *s2, size_t n) =========================================================== #include int ppoll(struct pollfd *restrict fds, nfds_t nfds, const struct timespec *restrict timeout, const sigset_t *restrict sigmask); The ppoll() function is a GNU/Linux extension. =========================================================== #include ssize_t getdelim(char **restrict, size_t *restrict, int, FILE *restrict); ssize_t getline(char **restrict, size_t *restrict, FILE *restrict); The getdelim() and getline() functions are specified in SUSv4. =========================================================== #include void *memmem(const void *, size_t, const void *, size_t); The memmem() function is a GNU/Linux and FreeBSD extension. =========================================================== #include int fcloseall(void); The fcloseall() function is a GNU/Linux and FreeBSD extension. =========================================================== #include int clearenv(void); The clearenv() function is a GNU/Linux extension. =========================================================== The semantics of the following existing function have changed a bit, as specified in SUSv4: #include char *realpath(const char *file_name, char *resolved_name); In particular, the semantics for 'resolved_name' being passed in as a NULL pointer have changed. Previously, this resulted in failure with errno == EINVAL. Now, realpath() allocates a buffer using malloc(): If resolved_name is a null pointer, the generated pathname shall be stored as a null-terminated string in a buffer allocated as if by a call to malloc(). =========================================================== #include char *canonicalize_file_name(const char *path); The canonicalize_file_name() function is a GNU/Linux extension. It is equivalent to realpath(path, NULL) (see above). =========================================================== #include int ffsl(long); int ffsll(long long); int fls(int); int flsl(long); int flsll(long long); These functions are FreeBSD extensions. =========================================================== #include const char *getprogname(void); void setprogname(const char *progname); In addition, this global variable will be added to libc: const char *__progname; However, Following FreeBSD's lead, the __progname variable, even though it will exist, will not be declared in any header file, and it will be versioned as SUNWprivate_1.1. Applications that want to use it will have to declare it explicitly. The getprogname() and setprogname() functions and the __progname global variable are FreeBSD extensions. =========================================================== #include wchar_t *wcsdup(const wchar_t *); size_t wcsnlen(const wchar_t *, size_t); wchar_t *wcpcpy(wchar_t *restrict, const wchar_t *restrict); wchar_t *wcpncpy(wchar_t *restrict, const wchar_t *restrict, size_t); int wcscasecmp(const wchar_t *, const wchar_t *); int wcsncasecmp(const wchar_t *, const wchar_t *, size_t); These functions are specified in SUSv4. =========================================================== int get_nprocs(void); int get_nprocs_conf(void); The get_nprocs() and get_nprocs_conf() are GNU/Linux extensions equivalent, respectively, to: sysconf(_SC_NPROCESSORS_ONLN); sysconf(_SC_NPROCESSORS_CONF); =========================================================== Since SUSv4 changes are being made to the system, the following definitions are being added to , as specified in SUSv4, because these features already exist: _POSIX_THREAD_ROBUST_PRIO_INHERIT Implementation supports the Robust Mutex Priority Inheritance option. _POSIX_THREAD_ROBUST_PRIO_PROTECT Implementation supports the Robust Mutex Priority Protection option. _SC_THREAD_ROBUST_PRIO_INHERIT _SC_THREAD_ROBUST_PRIO_PROTECT =========================================================== 4. Manual pages. New and modified manual pages will be created from the SUSv4 POSIX specifications where the relevant functions are defined therein, and from GNU/Linux and FreeBSD manual pages otherwise. From joerg.schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Tue Aug 3 02:56:14 2010 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o739uE9r003173 for ; Tue, 3 Aug 2010 02:56:14 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o739uDqC014815 for ; Tue, 3 Aug 2010 02:56:13 -0700 (PDT) Received: from relay44i.sun.com ([192.5.209.118]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o739lp9G022490 for ; Tue, 3 Aug 2010 09:56:13 GMT Received: from mmp41es.mmp.us.syntegra.com ([160.41.221.10] [160.41.221.10]) by relay44i.sun.com with ESMTP id BT-MMP-38117 for psarc-ext@sac.sfbay.sun.com; Tue, 3 Aug 2010 09:56:12 Z Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mmp41es.mmp.us.syntegra.com with ESMTP id BT-MMP-59037003 for psarc-ext@sac.sfbay.sun.com; Tue, 3 Aug 2010 09:56:11 Z Received: from relay03-haj2.antispameurope.com ([83.246.65.53] [83.246.65.53]) by relay4i.sun.com with ESMTP id BT-MMP-2208994 for psarc-ext@sac.sfbay.sun.com; Tue, 3 Aug 2010 09:56:11 Z Received: by relay03-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 26FCD63C186; Tue, 3 Aug 2010 11:56:09 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay03-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 6F17B63C172; Tue, 3 Aug 2010 11:56:08 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id o739u88m006362; Tue, 3 Aug 2010 11:56:08 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Aug 2010 11:56:07 +0200 Date: Tue, 03 Aug 2010 11:56:07 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) To: roger.faulkner@oracle.com, Gordon.Ross@oracle.com Cc: scott.michael@oracle.com, psarc-ext@sac.sfbay.sun.com, jeff.bonwick@oracle.com, brendan.doyle@oracle.com Subject: Re: GNU/Linux/BSD compatibility functions [PSARC/2010/299 FastTrack timeout, 08/04/2010] Message-ID: <4c57e7b7.0Y8YdLLNbovlOYan%Joerg.Schilling@fokus.fraunhofer.de> References: <4C50C02E.5070007@oracle.com> <1280423787.1236.7.camel@localhost> <4C5716CB.1020209@oracle.com> <4C576EAA.4040101@oracle.com> In-Reply-To: <4C576EAA.4040101@oracle.com> User-Agent: nail 11.22 3/20/05 X-Brightmail-Tracker: AAAAAA== X-OriginalArrivalTime: 03 Aug 2010 09:56:07.0659 (UTC) FILETIME=[180423B0:01CB32F2] X-Antispam: No, score=-0.2/5.0, scanned in 0.757sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: joerg.schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Status: RO Content-Length: 1213 "Roger A. Faulkner" wrote: > In addition to existing in GNU/Linux/BSD manual pages, many > of these functions are also specified in the new POSIX standard: > IEEE Std 1003.1(TM)-2008 > The Open Group Technical Standard > Base Specifications, Issue 7 > hereinafter referred to as SUSv4. While you remind me of the new POSIX standard.... I found that recent kernel includefiles finally have O_SEARCH but there seems to be no support code in the kernel. In order to bve able to implement path names of unlimited length in star, I would need full O_SEARCH support and in addition, I would need a function: pathconfat(int fd, const char *path, int name, int flags); The "flags" argument was a proposal from the POSIX mailing list after I mentioned that this function is needed. Is there a chance to get support for long path names in Solaris? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From roger.faulkner@oracle.com Tue Aug 3 06:15:26 2010 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o73DFQeN005334 for ; Tue, 3 Aug 2010 06:15:26 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o73DFP4j007168 for ; Tue, 3 Aug 2010 06:15:26 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o73DFPA1025764 for ; Tue, 3 Aug 2010 13:15:25 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o733c3Kt013752; Tue, 3 Aug 2010 13:15:22 GMT Received: from abhmt019.oracle.com by acsmt353.oracle.com with ESMTP id 480216761280841225; Tue, 03 Aug 2010 06:13:45 -0700 Received: from [10.7.251.247] (/10.7.251.247) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 03 Aug 2010 06:13:44 -0700 Message-ID: <4C581604.6030005@oracle.com> Date: Tue, 03 Aug 2010 09:13:40 -0400 From: "Roger A. Faulkner" User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.9.2.4) Gecko/20100705 Lightning/1.0b2 Thunderbird/3.1 MIME-Version: 1.0 To: Joerg.Schilling@fokus.fraunhofer.de CC: Gordon.Ross@oracle.com, scott.michael@oracle.com, psarc-ext@sac.sfbay.sun.com, jeff.bonwick@oracle.com, brendan.doyle@oracle.com Subject: Re: GNU/Linux/BSD compatibility functions [PSARC/2010/299 FastTrack timeout, 08/04/2010] References: <4C50C02E.5070007@oracle.com> <1280423787.1236.7.camel@localhost> <4C5716CB.1020209@oracle.com> <4C576EAA.4040101@oracle.com> <4c57e7b7.0Y8YdLLNbovlOYan%Joerg.Schilling@fokus.fraunhofer.de> In-Reply-To: <4c57e7b7.0Y8YdLLNbovlOYan%Joerg.Schilling@fokus.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4C58166B.001E:SCFMA4539814,ss=1,fgs=0 Status: RO Content-Length: 1689 On 08/03/10 05:56, Joerg.Schilling@fokus.fraunhofer.de wrote: > "Roger A. Faulkner" wrote: > >> In addition to existing in GNU/Linux/BSD manual pages, many >> of these functions are also specified in the new POSIX standard: >> IEEE Std 1003.1(TM)-2008 >> The Open Group Technical Standard >> Base Specifications, Issue 7 >> hereinafter referred to as SUSv4. > While you remind me of the new POSIX standard.... > I found that recent kernel includefiles finally have O_SEARCH > but there seems to be no support code in the kernel. Yes there is. Look for this symbol in the kernel: #define FSEARCH 0x200000 /* O_SEARCH = 0x200000 */ You can successfully open a directory with O_SEARCH when the permissions allow only search (d--x--x--x, plus ACL considerations). You can then use that file descriptor as the starting file descriptor for any of the *at() functions. > In order to bve able to implement path names of unlimited length in star, > I would need full O_SEARCH support and in addition, I would need a function: > > pathconfat(int fd, const char *path, int name, int flags); > > The "flags" argument was a proposal from the POSIX mailing list after I > mentioned that this function is needed. Can you privately point me to a discussion of that (as yet unspecified by the new standard) function? It looks useful, but I won't do it until the interface specification is stable. This is not part of the current PSARC case, though. It's a possible future work. > Is there a chance to get support for long path names in Solaris? It's mostly there (all except for pathconfat()). Roger From sebastien.roy@ORACLE.COM Wed Aug 4 11:20:37 2010 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o74IKbXs010838 for ; Wed, 4 Aug 2010 11:20:37 -0700 (PDT) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o74IKb2T007796 for ; Wed, 4 Aug 2010 11:20:37 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o74IKWLP028890 for ; Wed, 4 Aug 2010 18:20:32 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o74I6ohK032580 for ; Wed, 4 Aug 2010 18:20:31 GMT Received: from abhmt018.oracle.com by acsmt355.oracle.com with ESMTP id 466236401280945970; Wed, 04 Aug 2010 11:19:30 -0700 Received: from [129.148.174.103] (/129.148.174.103) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 04 Aug 2010 11:19:29 -0700 Message-ID: <4C59AF30.3010805@oracle.com> Date: Wed, 04 Aug 2010 14:19:28 -0400 From: Sebastien Roy User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.7) Gecko/20100717 Lightning/1.0b2pre Thunderbird/3.1.1 MIME-Version: 1.0 To: "Roger A. Faulkner" CC: Gordon Ross , brendan.doyle@ORACLE.COM, jeff.bonwick@ORACLE.COM, psarc-ext@sac.sfbay.sun.com, Scott Michael Subject: Re: GNU/Linux/BSD compatibility functions [PSARC/2010/299 FastTrack timeout, 08/04/2010] References: <4C50C02E.5070007@oracle.com> <1280423787.1236.7.camel@localhost> <4C5716CB.1020209@oracle.com> <4C576EAA.4040101@oracle.com> In-Reply-To: <4C576EAA.4040101@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4C59AF6F.01AB:SCFMA4539814,ss=1,fgs=0 Status: RO Content-Length: 543 On 08/ 2/10 09:19 PM, Roger A. Faulkner wrote: > As a result of suggestions made in the email for this case, > I am sending this revised, final version of the proposal > (with additional bugids included and with the description > of getprogname(), setprogname() and __progname included): This case was approved during today's PSARC meeting. I know Garrett gave the case a +1 before the spec was updated, and I've just reviewed the updated spec and give it a +1 as well. I assume that Garrett has no issues with the updated spec... -Seb