From casper@sac.sfbay.sun.com Tue Feb 10 04:40:51 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1ACepFC025694 for ; Tue, 10 Feb 2009 04:40:51 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1ACeo3d027897; Tue, 10 Feb 2009 04:40:50 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KEU00307OK2MC00@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Feb 2009 04:40:50 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEU00LA0OK2VK40@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Feb 2009 04:40:50 -0800 (PST) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n1ACeoi6036176; Tue, 10 Feb 2009 04:40:50 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1ACemWR025689; Tue, 10 Feb 2009 04:40:48 -0800 (PST) Received: (from casper@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n1ACemJM025685; Tue, 10 Feb 2009 04:40:48 -0800 (PST) Date: Tue, 10 Feb 2009 04:40:48 -0800 (PST) From: Casper Dik Subject: stpcpy, stpncpy, wcpcpy, wcpncpy in lib C [PSARC/2009/084 Self Review] To: PSARC-ext@sun.com Cc: roland.mainz@nrubsig.org Message-id: <200902101240.n1ACemJM025685@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 8530 Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: stpcpy, stpncpy, wcpcpy, wcpncpy in lib C 1.2. Name of Document Author/Supplier: Author: Roland Mainz 1.3 Date of This Document: 10 February, 2009 4. Technical Description I am sponsoring this automatic case for Roland Mainz as one of the spin-offs of the ksh93-integration project. 1. Introduction This case adds four new functions to the C library, |stpcpy()|, |stpncpy()|, |wcpcpy()| and |wcpncpy()| as follows: char *stpcpy(char *restrict s1, const char *restrict s2); char *stpncpy(char *restrict s1, const char *restrict s2, size_t n); wchar_t *wcpcpy(wchar_t restrict *ws1, const wchar_t *restrict ws2); wchar_t *wcpncpy(wchar_t restrict *ws1, const wchar_t *restrict ws2, size_t n); The committment level of these interfaces is "Committed". The release binding is "patch" (so it can be back-ported to Solaris 10 if required). The code may be shared with the AST/ksh93 codebase. 2. Discussion Linux, the various BSD operating systems and now IEEE Std 1003.1-2008 provide the { |stpcpy()|, |stpncpy()|, |wcpcpy()|, |wcpncpy()| }-family of functions. These behave similar as the |str*cpy()|/|wcs*cpy()| family of functions, except that they return a pointer to the _end_ of the buffer instead of the beginning, allowing efficient concaternation of strings. 3. Interface table All four functions are "Committed". 4. References Bugster CR #6793969 RFE: Add |stpcpy| to libc http://www.opengroup.org/onlinepubs/9699919799/functions/stpcpy.html http://www.opengroup.org/onlinepubs/9699919799/functions/stpncpy.html http://www.opengroup.org/onlinepubs/9699919799/functions/wcpcpy.html http://www.opengroup.org/onlinepubs/9699919799/functions/wcpncpy.html 5. Manual page differences (same as manpagediffs.txt in the materials/ section) ---- snip ---- --- string.3c.old.txt Thu Jan 22 17:35:48 2009 +++ string.3c.new.txt Thu Jan 22 18:13:36 2009 @@ -7,9 +7,9 @@ NAME string, strcasecmp, strncasecmp, strcat, strncat, strlcat, - strchr, strrchr, strcmp, strncmp, strcpy, strncpy, strlcpy, - strcspn, strspn, strdup, strlen, strpbrk, strstr, strtok, - strtok_r - string operations + strchr, strrchr, strcmp, strncmp, strcpy, strncpy, stpcpy, + stpncpy, strlcpy, strcspn, strspn, strdup, strlen, strpbrk, + strstr, strtok, strtok_r - string operations SYNOPSIS #include @@ -36,9 +36,14 @@ int strncmp(const char *s1, const char *s2, size_t n); char *strcpy(char *restrict s1, const char *restrict s2); + + char *stpcpy(char *restrict s1, const char *restrict s2); char *strncpy(char *restrict s1, const char *restrict s2, size_t n); + + char *stpncpy(char *restrict s1, const char *restrict s2, + size_t n); size_t strlcpy(char *dst, const char *src, size_t dstsize); @@ -97,9 +102,10 @@ DESCRIPTION The arguments s, s1, and s2 point to strings (arrays of characters terminated by a null character). The strcat(), - strncat(), strlcat(), strcpy(), strncpy(), strlcpy(), - strtok(), and strtok_r() functions all alter their first - argument. These functions do not check for overflow of the + strncat(), strlcat(), strcpy(), strncpy(), stpcpy(), + stpncpy(), strlcpy(), strtok(), and strtok_r() functions + all alter their first argument. + These functions do not check for overflow of the array pointed to by the first argument. strcasecmp(), strncasecmp() @@ -170,13 +176,19 @@ but looks at a maximum of n bytes. Bytes following a null byte are not compared. - strcpy(), strncpy(), strlcpy() - The strcpy() function copies string s2 to s1, including the - terminating null character, stopping after the null charac- - ter has been copied. The strncpy() function copies exactly n - bytes, truncating s2 or adding null characters to s1 if - necessary. The result will not be null-terminated if the - length of s2 is n or more. Each function returns s1. + strcpy(), strncpy(), stpcpy(), stpncpy(), strlcpy() + The strcpy() and stpcpy() functions copy string s2 to s1, + including the terminating null character, stopping after + the null character has been copied. The strncpy() and + stpncpy() functions copy exactly n bytes, truncating s2 + or adding null characters to s1 if necessary. The result + will not be null-terminated if the length of s2 is n + or more. + strcpy(), strncpy() return returns s1, functions stpcpy() + and stpncpy() return a pointer to the terminating NULL + character copied into the s1 buffer or (if s2 does not fit + into n (and therefore no terminating NULL character was + written)) returns &s1[n]. The strlcpy() function copies at most dstsize-1 characters (dstsize being the size of the string buffer dst) from src --- wcstring.3c.old.txt Thu Jan 22 17:36:07 2009 +++ wcstring.3c.new.txt Thu Jan 22 18:13:20 2009 @@ -7,10 +7,10 @@ NAME wcstring, wcscat, wscat, wcsncat, wsncat, wcscmp, wscmp, - wcsncmp, wsncmp, wcscpy, wscpy, wcsncpy, wsncpy, wcslen, - wslen, wcschr, wschr, wcsrchr, wsrchr, windex, wrindex, - wcspbrk, wspbrk, wcswcs, wcsspn, wsspn, wcscspn, wscspn, - wcstok, wstok - wide-character string operations + wcsncmp, wsncmp, wcscpy, wcpcpy, wcpncpy, wscpy, wcsncpy, + wsncpy, wcslen, wslen, wcschr, wschr, wcsrchr, wsrchr, + windex, wrindex, wcspbrk, wspbrk, wcswcs, wcsspn, wsspn, + wcscspn, wscspn, wcstok, wstok - wide-character string operations SYNOPSIS #include @@ -30,6 +30,10 @@ wchar_t *wcsncpy(wchar_t *restrict ws1, const wchar_t *res- trict ws2, size_t n); + wchar_t *wcpcpy(wchar_t restrict *ws1, const wchar_t *restrict ws2); + wchar_t *wcpncpy(wchar_t restrict *ws1, const wchar_t *restrict ws2, + size_t n); + size_t wcslen(const wchar_t *ws); wchar_t *wcschr(const wchar_t *ws, wchar_t wc); @@ -187,7 +191,7 @@ equal to, or less than the possibly null-terminated array pointed to by ws2. - wcscpy(), wscpy() + wcscpy(), wscpy(), wcpcpy() @@ -203,14 +207,16 @@ - The wcscpy() and wscpy() functions copy the wide-character - string pointed to by ws2 (including the terminating null - wide-character code) into the array pointed to by ws1. If - copying takes place between objects that overlap, the - behavior is undefined. Both functions return ws1; no return - value is reserved to indicate an error. + The wcscpy(), wscpy() and wcpcpy() functions copy the + wide-character string pointed to by ws2 (including the + terminating null wide-character code) into the array pointed + to by ws1. If copying takes place between objects + that overlap, the behavior is undefined. wcscpy(), wscpy() + return ws1, function wcpcpy() returns a pointer to the + terminating NULL character; + no return value is reserved to indicate an error. - wcsncpy(), wsncpy() + wcsncpy(), wsncpy(), wcpncpy() The wcsncpy() and wsncpy() functions copy not more than n wide-character codes (wide-character codes that follow a null wide character code are not copied) from the array @@ -220,8 +226,11 @@ character string that is shorter than n wide-character codes, null wide-character codes are appended to the copy in the array pointed to by ws1, until a total n wide-character - codes are written. Both functions return ws1; no return - value is reserved to indicate an error. + codes are written. wcsncpy(), wsncpy() return ws1, + function wcpncpy() returns a pointer to the terminating NULL + character copied into the ws1 buffer or (if ws2 does not fit + into n (and therefore no terminating NULL character was + written)) returns &ws1[n]. wcslen(), wslen() The wcslen() and wslen() functions compute the number of ---- snip ---- 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: os-net 6.5. ARC review type: Automatic 6.6. ARC Exposure: open From carlsonj@phorcys.east.sun.com Tue Feb 10 05:10:37 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1ADAa0f026474 for ; Tue, 10 Feb 2009 05:10:37 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n1ADAR2q018999 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.Com>; Tue, 10 Feb 2009 13:10:35 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KEU00I1FPXMA900@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Tue, 10 Feb 2009 05:10:34 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEU00E4ZPXMHF30@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Tue, 10 Feb 2009 05:10:34 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n1AD2vX6004417; Tue, 10 Feb 2009 08:02:57 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n1AD2v02004414; Tue, 10 Feb 2009 08:02:57 -0500 (EST) Date: Tue, 10 Feb 2009 08:02:57 -0500 From: James Carlson Subject: Re: stpcpy, stpncpy, wcpcpy, wcpncpy in lib C [PSARC/2009/084 Self Review] In-reply-to: <200902101240.n1ACemJM025685@sac.sfbay.sun.com> To: Casper Dik Cc: PSARC-ext@sun.com, roland.mainz@nrubsig.org Message-id: <18833.31489.181789.352638@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200902101240.n1ACemJM025685@sac.sfbay.sun.com> Status: RO Content-Length: 1150 Casper Dik writes: > char *stpcpy(char *restrict s1, const char *restrict s2); > char *stpncpy(char *restrict s1, const char *restrict s2, size_t n); > wchar_t *wcpcpy(wchar_t restrict *ws1, const wchar_t *restrict ws2); > wchar_t *wcpncpy(wchar_t restrict *ws1, const wchar_t *restrict ws2, size_t > n); The lint maintainers be notified so that they can add stpcpy and wcpcpy to their list of security-questionable functions warned about via -errsecurity. (At least file an RFE.) This looks to me like a standards-related blunder. "stpncpy" and "wcpncpy" functionality (strncpy-like zero pad to end of the buffer, *and* leaving full destination buffers unterminated) doesn't seem to make much sense in this context. I think it's a shame they didn't do stplcpy and wcplcpy instead. Do we have anyone involved in the standards process who could add comments? Apart from that, big sigh, nose held, and +1. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From roland.mainz@nrubsig.org Tue Feb 10 05:32:13 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1ADWDTE027089 for ; Tue, 10 Feb 2009 05:32:13 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1ADWA0I025451; Tue, 10 Feb 2009 05:32:12 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KEU00709QXNFA00@brm-avmta-1.central.sun.com>; Tue, 10 Feb 2009 06:32:11 -0700 (MST) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEU00JHSQXMIBC0@brm-avmta-1.central.sun.com>; Tue, 10 Feb 2009 06:32:10 -0700 (MST) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n1ADLdtF029636; Tue, 10 Feb 2009 13:32:10 +0000 (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-4378268; Tue, 10 Feb 2009 13:32:10 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-210645; Tue, 10 Feb 2009 13:32:09 +0000 (Z) Received: from mail-in-05.arcor-online.net ([151.189.21.45] [151.189.21.45]) by relay1i.sun.com with ESMTP id BT-MMP-5692034; Tue, 10 Feb 2009 13:32:09 +0000 (Z) Received: from mail-in-03-z2.arcor-online.net (mail-in-03-z2.arcor-online.net [151.189.8.15]) by mx.arcor.de (Postfix) with ESMTP id B524137E7B4; Tue, 10 Feb 2009 14:29:44 +0100 (CET) Received: from mail-in-17.arcor-online.net (mail-in-17.arcor-online.net [151.189.21.57]) by mail-in-03-z2.arcor-online.net (Postfix) with ESMTP id 993982D3783; Tue, 10 Feb 2009 14:29:44 +0100 (CET) Received: from jupiterb48.nrubsig.org (dslb-094-219-209-239.pools.arcor-ip.net [94.219.209.239]) by mail-in-17.arcor-online.net (Postfix) with ESMTPS id B90DC3B3089; Tue, 10 Feb 2009 14:29:43 +0100 (CET) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id n1ADTfmp015566; Tue, 10 Feb 2009 14:29:41 +0100 (CET) Date: Tue, 10 Feb 2009 14:29:41 +0100 From: Roland Mainz Subject: Re: stpcpy, stpncpy, wcpcpy, wcpncpy in lib C [PSARC/2009/084 Self Review] Sender: gisburn@jupiterb48.nrubsig.org To: James Carlson Cc: Casper Dik , PSARC-ext@sun.com Message-id: <49918145.1BA0C4BD@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DKIM: Sendmail DKIM Filter v2.6.0 mail-in-17.arcor-online.net B90DC3B3089 X-Virus-Scanned: ClamAV 0.94.2/8973/Tue Feb 10 11:42:02 2009 on mail-in-17.arcor-online.net X-Virus-Status: Clean X-Antispam: No, score=0.0/5.0, scanned in 0.111sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200902101240.n1ACemJM025685@sac.sfbay.sun.com> <18833.31489.181789.352638@gargle.gargle.HOWL> Status: RO Content-Length: 1863 James Carlson wrote: > Casper Dik writes: > > char *stpcpy(char *restrict s1, const char *restrict s2); > > char *stpncpy(char *restrict s1, const char *restrict s2, size_t n); > > wchar_t *wcpcpy(wchar_t restrict *ws1, const wchar_t *restrict ws2); > > wchar_t *wcpncpy(wchar_t restrict *ws1, const wchar_t *restrict ws2, size_t > > n); > > The lint maintainers be notified so that they can add stpcpy and > wcpcpy to their list of security-questionable functions warned about > via -errsecurity. (At least file an RFE.) Erm... are both |strcpy()| and |strcat()| in this list, too ? > This looks to me like a standards-related blunder. "stpncpy" and > "wcpncpy" functionality (strncpy-like zero pad to end of the buffer, > *and* leaving full destination buffers unterminated) doesn't seem to > make much sense in this context. My primary interest was |stpcpy()| to get performance of the locale codepaths fixed (we assume that we check at the _beginning_ that all allocated buffers have sufficient size (since the use of something like |stplcpy()| would completely kill the performance advantage since more registers and more operations are required for string copies)). Right now these codepaths are seveal _factors_ (more than 2x) _slower_ than on Linux and one of the primary "root cause" is the over-use of inefficient buffer handling (whic hwe try to partially address with the use of |stpcpy()|). > I think it's a shame they didn't do stplcpy and wcplcpy instead. Do > we have anyone involved in the standards process who could add > comments? Don Cragun was RIF'ed and right now I don't know anyone at Sun who can be queried for standards issues. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From casper@holland.sun.com Tue Feb 10 05:49:19 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1ADnJTK027571 for ; Tue, 10 Feb 2009 05:49:19 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1ADnEdf001053 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Tue, 10 Feb 2009 06:49:19 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KEU00705RQ5DK00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 10 Feb 2009 05:49:17 -0800 (PST) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEU00LDHRQ3VK90@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 10 Feb 2009 05:49:16 -0800 (PST) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n1ADnB2Y026019; Tue, 10 Feb 2009 13:49:11 +0000 (GMT) Date: Tue, 10 Feb 2009 14:49:26 +0100 From: Casper.Dik@sun.com Subject: Re: stpcpy, stpncpy, wcpcpy, wcpncpy in lib C [PSARC/2009/084 Self Review] In-reply-to: <49918145.1BA0C4BD@nrubsig.org> Sender: casper@holland.sun.com To: Roland Mainz Cc: James Carlson , Casper Dik , PSARC-ext@sun.com Message-id: <200902101349.n1ADnB2Y026019@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200902101240.n1ACemJM025685@sac.sfbay.sun.com> <18833.31489.181789.352638@gargle.gargle.HOWL> <49918145.1BA0C4BD@nrubsig.org> Status: RO Content-Length: 1580 >James Carlson wrote: >> Casper Dik writes: >> > char *stpcpy(char *restrict s1, const char *restrict s2); >> > char *stpncpy(char *restrict s1, const char *restrict s2, size_t n); >> > wchar_t *wcpcpy(wchar_t restrict *ws1, const wchar_t *restrict ws2); >> > wchar_t *wcpncpy(wchar_t restrict *ws1, const wchar_t *restrict ws2, size_t >> > n); >> >> The lint maintainers be notified so that they can add stpcpy and >> wcpcpy to their list of security-questionable functions warned about >> via -errsecurity. (At least file an RFE.) > >Erm... are both |strcpy()| and |strcat()| in this list, too ? Yes. >> This looks to me like a standards-related blunder. "stpncpy" and >> "wcpncpy" functionality (strncpy-like zero pad to end of the buffer, >> *and* leaving full destination buffers unterminated) doesn't seem to >> make much sense in this context. > >My primary interest was |stpcpy()| to get performance of the locale >codepaths fixed (we assume that we check at the _beginning_ that all >allocated buffers have sufficient size (since the use of something like >|stplcpy()| would completely kill the performance advantage since more >registers and more operations are required for string copies)). Right >now these codepaths are seveal _factors_ (more than 2x) _slower_ than on >Linux and one of the primary "root cause" is the over-use of inefficient >buffer handling (whic hwe try to partially address with the use of >|stpcpy()|). stplcpy would be difficult to implement, except if you add another pointer (pointer to the base of the buffer) Casper From carlsonj@phorcys.east.sun.com Tue Feb 10 05:56:51 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1ADuo1O028180 for ; Tue, 10 Feb 2009 05:56:51 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1ADun1p005820 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 10 Feb 2009 06:56:50 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KEU0071AS2PQY00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Feb 2009 05:56:49 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEU00L70S2OVT90@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Feb 2009 05:56:48 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n1ADnCEa004573; Tue, 10 Feb 2009 08:49:12 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n1ADnCga004570; Tue, 10 Feb 2009 08:49:12 -0500 (EST) Date: Tue, 10 Feb 2009 08:49:12 -0500 From: James Carlson Subject: Re: stpcpy, stpncpy, wcpcpy, wcpncpy in lib C [PSARC/2009/084 Self Review] In-reply-to: <49918145.1BA0C4BD@nrubsig.org> To: Roland Mainz Cc: Casper Dik , PSARC-ext@sun.com Message-id: <18833.34264.205444.470184@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200902101240.n1ACemJM025685@sac.sfbay.sun.com> <18833.31489.181789.352638@gargle.gargle.HOWL> <49918145.1BA0C4BD@nrubsig.org> Status: RO Content-Length: 3884 Roland Mainz writes: > James Carlson wrote: > > Casper Dik writes: > > > char *stpcpy(char *restrict s1, const char *restrict s2); > > > char *stpncpy(char *restrict s1, const char *restrict s2, size_t n); > > > wchar_t *wcpcpy(wchar_t restrict *ws1, const wchar_t *restrict ws2); > > > wchar_t *wcpncpy(wchar_t restrict *ws1, const wchar_t *restrict ws2, size_t > > > n); > > > > The lint maintainers be notified so that they can add stpcpy and > > wcpcpy to their list of security-questionable functions warned about > > via -errsecurity. (At least file an RFE.) > > Erm... are both |strcpy()| and |strcat()| in this list, too ? Yes. From the lint documentation: -errsecurity=v Use the -errsecurity option to check your code for security loopholes. v must be one of the following: core, standard, security, or %none. If you do not specify a setting for -errsecurity, the lint sets it to -errsecury=%none. If you do specify -errsecurity but not an argument, the lint sets it to -errsecurity=standard. [...] standard This level includes all checks from the core level plus checks for constructs that may be safe, but have better alternatives available. This level is well suited for newly-written code. Additional checks at this level include: o Use of string copy functions other than strlcpy() Both strcpy and strcat (as well as the 'n' versions) are called "bad" by this feature of lint, because they can be hard to use in a safe way, and some of the ON code *does* normally lint for security. See this CR: 4877995 Add checking for insecure coding practices to lint and these: 4983584 Enable lint -errsecurity option 5048098 lint cleaning bfs.c 5048117 Lint cleaning diskscan.c 5063982 libsldap is not lint clean if -errsecurity=standard is turned on > > This looks to me like a standards-related blunder. "stpncpy" and > > "wcpncpy" functionality (strncpy-like zero pad to end of the buffer, > > *and* leaving full destination buffers unterminated) doesn't seem to > > make much sense in this context. > > My primary interest was |stpcpy()| to get performance of the locale > codepaths fixed (we assume that we check at the _beginning_ that all > allocated buffers have sufficient size (since the use of something like > |stplcpy()| would completely kill the performance advantage since more > registers and more operations are required for string copies)). Right > now these codepaths are seveal _factors_ (more than 2x) _slower_ than on > Linux and one of the primary "root cause" is the over-use of inefficient > buffer handling (whic hwe try to partially address with the use of > |stpcpy()|). Without a decent implementation of stplcpy and an exact cycle count proving your case, I'm just not going to buy that argument. On modern CPUs, the costs of fetching the data typically dominate so much that control structures of this sort (two extra instructions per cycle; decrementing a register and a branch test) are completely hidden. They merely fill stall cycles. Using stpcpy over stplcpy (or any similar bounded function) sounds like a false economy to me. > > I think it's a shame they didn't do stplcpy and wcplcpy instead. Do > > we have anyone involved in the standards process who could add > > comments? > > Don Cragun was RIF'ed and right now I don't know anyone at Sun who can > be queried for standards issues. Nor do I, which is why I was bringing it up here. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From carlsonj@phorcys.east.sun.com Tue Feb 10 06:08:19 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1AE8JvX028769 for ; Tue, 10 Feb 2009 06:08:19 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n1AE8ExH025619; Tue, 10 Feb 2009 14:08:17 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KEU0020LSLQ7900@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Feb 2009 06:08:14 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEU00E5FSLPHF90@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Feb 2009 06:08:13 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n1AE0bvT004616; Tue, 10 Feb 2009 09:00:37 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n1AE0bNX004613; Tue, 10 Feb 2009 09:00:37 -0500 (EST) Date: Tue, 10 Feb 2009 09:00:37 -0500 From: James Carlson Subject: Re: stpcpy, stpncpy, wcpcpy, wcpncpy in lib C [PSARC/2009/084 Self Review] In-reply-to: <200902101349.n1ADnB2Y026019@dm-holland-02.uk.sun.com> To: Casper.Dik@sun.com Cc: Roland Mainz , Casper Dik , PSARC-ext@sun.com Message-id: <18833.34949.513294.533522@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200902101240.n1ACemJM025685@sac.sfbay.sun.com> <18833.31489.181789.352638@gargle.gargle.HOWL> <49918145.1BA0C4BD@nrubsig.org> <200902101349.n1ADnB2Y026019@dm-holland-02.uk.sun.com> Status: RO Content-Length: 1276 Casper.Dik@Sun.COM writes: > >My primary interest was |stpcpy()| to get performance of the locale > >codepaths fixed (we assume that we check at the _beginning_ that all > >allocated buffers have sufficient size (since the use of something like > >|stplcpy()| would completely kill the performance advantage since more > >registers and more operations are required for string copies)). Right > >now these codepaths are seveal _factors_ (more than 2x) _slower_ than on > >Linux and one of the primary "root cause" is the over-use of inefficient > >buffer handling (whic hwe try to partially address with the use of > >|stpcpy()|). > > stplcpy would be difficult to implement, except if you add another pointer > (pointer to the base of the buffer) It only needs to be analogous to strlcpy, not strlcat. char * stplcpy(char *dst, const char *src, size_t dlen) { /* allow for terminating NUL in all cases */ if (dlen-- == 0) return (dst); while (dlen-- > 0) { if ((*dst++ = *src++) == '\0) return (dst - 1); } *dst = '\0'; return (dst); } -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From gdamore@sun.com Tue Feb 10 07:48:51 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1AFmoqT003307 for ; Tue, 10 Feb 2009 07:48:50 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1AFmmop020591 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 10 Feb 2009 08:48:50 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KEU00D09X9CMW00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Tue, 10 Feb 2009 07:48:48 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEU00B9EX9CM230@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Tue, 10 Feb 2009 07:48:48 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n1AFmmGU027900 for ; Tue, 10 Feb 2009 07:48:48 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KEU00I00X5FGQ00@fe-sfbay-09.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Tue, 10 Feb 2009 07:48:48 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KEU00I27X9BN110@fe-sfbay-09.sun.com>; Tue, 10 Feb 2009 07:48:48 -0800 (PST) Date: Tue, 10 Feb 2009 07:48:47 -0800 From: "Garrett D'Amore" Subject: Re: stpcpy, stpncpy, wcpcpy, wcpncpy in lib C [PSARC/2009/084 Self Review] In-reply-to: <200902101240.n1ACemJM025685@sac.sfbay.sun.com> Sender: Garrett.Damore@sun.com To: Casper Dik Cc: PSARC-ext@sun.com, roland.mainz@nrubsig.org Message-id: <4991A1DF.3060707@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200902101240.n1ACemJM025685@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 9115 +1. Do we know who's taken over Don Cragun's POSIX duties? It would be nice to have this reviewed by whoever our standards czar is. - Garrett Casper Dik wrote: > Template Version: @(#)sac_nextcase %I% %G% SMI > This information is Copyright 2009 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > stpcpy, stpncpy, wcpcpy, wcpncpy in lib C > 1.2. Name of Document Author/Supplier: > Author: Roland Mainz > 1.3 Date of This Document: > 10 February, 2009 > 4. Technical Description > I am sponsoring this automatic case for Roland Mainz as one of the spin-offs > of the ksh93-integration project. > > 1. Introduction > > This case adds four new functions to the C library, > |stpcpy()|, |stpncpy()|, |wcpcpy()| and |wcpncpy()| as follows: > > char *stpcpy(char *restrict s1, const char *restrict s2); > char *stpncpy(char *restrict s1, const char *restrict s2, size_t n); > wchar_t *wcpcpy(wchar_t restrict *ws1, const wchar_t *restrict ws2); > wchar_t *wcpncpy(wchar_t restrict *ws1, const wchar_t *restrict ws2, size_t > n); > > The committment level of these interfaces is "Committed". > > The release binding is "patch" > (so it can be back-ported to Solaris 10 if required). > > The code may be shared with the AST/ksh93 codebase. > > 2. Discussion > > Linux, the various BSD operating systems and now IEEE Std 1003.1-2008 > provide the { |stpcpy()|, |stpncpy()|, |wcpcpy()|, |wcpncpy()| }-family > of functions. These behave similar as the |str*cpy()|/|wcs*cpy()| > family of functions, except that they return a pointer to the _end_ > of the buffer instead of the beginning, allowing efficient concaternation > of strings. > > 3. Interface table > > All four functions are "Committed". > > 4. References > > Bugster CR #6793969 RFE: Add |stpcpy| to libc > http://www.opengroup.org/onlinepubs/9699919799/functions/stpcpy.html > http://www.opengroup.org/onlinepubs/9699919799/functions/stpncpy.html > http://www.opengroup.org/onlinepubs/9699919799/functions/wcpcpy.html > http://www.opengroup.org/onlinepubs/9699919799/functions/wcpncpy.html > > 5. Manual page differences > > (same as manpagediffs.txt in the materials/ section) > ---- snip ---- > --- string.3c.old.txt Thu Jan 22 17:35:48 2009 > +++ string.3c.new.txt Thu Jan 22 18:13:36 2009 > @@ -7,9 +7,9 @@ > > NAME > string, strcasecmp, strncasecmp, strcat, strncat, strlcat, > - strchr, strrchr, strcmp, strncmp, strcpy, strncpy, strlcpy, > - strcspn, strspn, strdup, strlen, strpbrk, strstr, strtok, > - strtok_r - string operations > + strchr, strrchr, strcmp, strncmp, strcpy, strncpy, stpcpy, > + stpncpy, strlcpy, strcspn, strspn, strdup, strlen, strpbrk, > + strstr, strtok, strtok_r - string operations > > SYNOPSIS > #include > @@ -36,9 +36,14 @@ > int strncmp(const char *s1, const char *s2, size_t n); > > char *strcpy(char *restrict s1, const char *restrict s2); > + > + char *stpcpy(char *restrict s1, const char *restrict s2); > > char *strncpy(char *restrict s1, const char *restrict s2, > size_t n); > + > + char *stpncpy(char *restrict s1, const char *restrict s2, > + size_t n); > > size_t strlcpy(char *dst, const char *src, size_t dstsize); > > @@ -97,9 +102,10 @@ > DESCRIPTION > The arguments s, s1, and s2 point to strings (arrays of > characters terminated by a null character). The strcat(), > - strncat(), strlcat(), strcpy(), strncpy(), strlcpy(), > - strtok(), and strtok_r() functions all alter their first > - argument. These functions do not check for overflow of the > + strncat(), strlcat(), strcpy(), strncpy(), stpcpy(), > + stpncpy(), strlcpy(), strtok(), and strtok_r() functions > + all alter their first argument. > + These functions do not check for overflow of the > array pointed to by the first argument. > > strcasecmp(), strncasecmp() > @@ -170,13 +176,19 @@ > but looks at a maximum of n bytes. Bytes following a null > byte are not compared. > > - strcpy(), strncpy(), strlcpy() > - The strcpy() function copies string s2 to s1, including the > - terminating null character, stopping after the null charac- > - ter has been copied. The strncpy() function copies exactly n > - bytes, truncating s2 or adding null characters to s1 if > - necessary. The result will not be null-terminated if the > - length of s2 is n or more. Each function returns s1. > + strcpy(), strncpy(), stpcpy(), stpncpy(), strlcpy() > + The strcpy() and stpcpy() functions copy string s2 to s1, > + including the terminating null character, stopping after > + the null character has been copied. The strncpy() and > + stpncpy() functions copy exactly n bytes, truncating s2 > + or adding null characters to s1 if necessary. The result > + will not be null-terminated if the length of s2 is n > + or more. > + strcpy(), strncpy() return returns s1, functions stpcpy() > + and stpncpy() return a pointer to the terminating NULL > + character copied into the s1 buffer or (if s2 does not fit > + into n (and therefore no terminating NULL character was > + written)) returns &s1[n]. > > The strlcpy() function copies at most dstsize-1 characters > (dstsize being the size of the string buffer dst) from src > --- wcstring.3c.old.txt Thu Jan 22 17:36:07 2009 > +++ wcstring.3c.new.txt Thu Jan 22 18:13:20 2009 > @@ -7,10 +7,10 @@ > > NAME > wcstring, wcscat, wscat, wcsncat, wsncat, wcscmp, wscmp, > - wcsncmp, wsncmp, wcscpy, wscpy, wcsncpy, wsncpy, wcslen, > - wslen, wcschr, wschr, wcsrchr, wsrchr, windex, wrindex, > - wcspbrk, wspbrk, wcswcs, wcsspn, wsspn, wcscspn, wscspn, > - wcstok, wstok - wide-character string operations > + wcsncmp, wsncmp, wcscpy, wcpcpy, wcpncpy, wscpy, wcsncpy, > + wsncpy, wcslen, wslen, wcschr, wschr, wcsrchr, wsrchr, > + windex, wrindex, wcspbrk, wspbrk, wcswcs, wcsspn, wsspn, > + wcscspn, wscspn, wcstok, wstok - wide-character string operations > > SYNOPSIS > #include > @@ -30,6 +30,10 @@ > wchar_t *wcsncpy(wchar_t *restrict ws1, const wchar_t *res- > trict ws2, size_t n); > > + wchar_t *wcpcpy(wchar_t restrict *ws1, const wchar_t *restrict ws2); > + wchar_t *wcpncpy(wchar_t restrict *ws1, const wchar_t *restrict ws2, > + size_t n); > + > size_t wcslen(const wchar_t *ws); > > wchar_t *wcschr(const wchar_t *ws, wchar_t wc); > @@ -187,7 +191,7 @@ > equal to, or less than the possibly null-terminated array > pointed to by ws2. > > - wcscpy(), wscpy() > + wcscpy(), wscpy(), wcpcpy() > > > > @@ -203,14 +207,16 @@ > > > > - The wcscpy() and wscpy() functions copy the wide-character > - string pointed to by ws2 (including the terminating null > - wide-character code) into the array pointed to by ws1. If > - copying takes place between objects that overlap, the > - behavior is undefined. Both functions return ws1; no return > - value is reserved to indicate an error. > + The wcscpy(), wscpy() and wcpcpy() functions copy the > + wide-character string pointed to by ws2 (including the > + terminating null wide-character code) into the array pointed > + to by ws1. If copying takes place between objects > + that overlap, the behavior is undefined. wcscpy(), wscpy() > + return ws1, function wcpcpy() returns a pointer to the > + terminating NULL character; > + no return value is reserved to indicate an error. > > - wcsncpy(), wsncpy() > + wcsncpy(), wsncpy(), wcpncpy() > The wcsncpy() and wsncpy() functions copy not more than n > wide-character codes (wide-character codes that follow a > null wide character code are not copied) from the array > @@ -220,8 +226,11 @@ > character string that is shorter than n wide-character > codes, null wide-character codes are appended to the copy in > the array pointed to by ws1, until a total n wide-character > - codes are written. Both functions return ws1; no return > - value is reserved to indicate an error. > + codes are written. wcsncpy(), wsncpy() return ws1, > + function wcpncpy() returns a pointer to the terminating NULL > + character copied into the ws1 buffer or (if ws2 does not fit > + into n (and therefore no terminating NULL character was > + written)) returns &ws1[n]. > > wcslen(), wslen() > The wcslen() and wslen() functions compute the number of > ---- snip ---- > > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > os-net > 6.5. ARC review type: Automatic > 6.6. ARC Exposure: open > > From roland.mainz@nrubsig.org Tue Feb 10 08:14:29 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1AGETx6024488 for ; Tue, 10 Feb 2009 08:14:29 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1AGEGhS020386; Tue, 10 Feb 2009 08:14:27 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KEU00M33YG1VC00@brm-avmta-1.central.sun.com>; Tue, 10 Feb 2009 09:14:25 -0700 (MST) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEU00AU7YFO6EC0@brm-avmta-1.central.sun.com>; Tue, 10 Feb 2009 09:14:12 -0700 (MST) Received: from relay42i.sun.com ([192.5.209.72]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n1AG5im6026652; Tue, 10 Feb 2009 16:14:12 +0000 (GMT) Received: from mmp41es.mmp.us.syntegra.com ([160.41.221.10] [160.41.221.10]) by relay42i.sun.com with ESMTP id BT-MMP-1067206; Tue, 10 Feb 2009 16:14:11 +0000 (Z) Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mmp41es.mmp.us.syntegra.com with ESMTP id BT-MMP-6056476; Tue, 10 Feb 2009 16:14:11 +0000 (Z) Received: from mail-in-03.arcor-online.net ([151.189.21.43] [151.189.21.43]) by relay4i.sun.com with ESMTP id BT-MMP-7885948; Tue, 10 Feb 2009 16:14:11 +0000 (Z) Received: from mail-in-04-z2.arcor-online.net (mail-in-04-z2.arcor-online.net [151.189.8.16]) by mx.arcor.de (Postfix) with ESMTP id 6A4AD16F495; Tue, 10 Feb 2009 17:14:10 +0100 (CET) Received: from mail-in-16.arcor-online.net (mail-in-16.arcor-online.net [151.189.21.56]) by mail-in-04-z2.arcor-online.net (Postfix) with ESMTP id 3A556ABB78; Tue, 10 Feb 2009 17:14:10 +0100 (CET) Received: from jupiterb48.nrubsig.org (dslb-094-219-209-239.pools.arcor-ip.net [94.219.209.239]) by mail-in-16.arcor-online.net (Postfix) with ESMTPS id D95B7258334; Tue, 10 Feb 2009 17:14:09 +0100 (CET) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id n1AGE7Ob015819; Tue, 10 Feb 2009 17:14:07 +0100 (CET) Date: Tue, 10 Feb 2009 17:14:07 +0100 From: Roland Mainz Subject: Re: stpcpy, stpncpy, wcpcpy, wcpncpy in lib C [PSARC/2009/084 Self Review] Sender: gisburn@jupiterb48.nrubsig.org To: James Carlson Cc: Casper Dik , PSARC-ext@sun.com Message-id: <4991A7CF.B1C1E0F3@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DKIM: Sendmail DKIM Filter v2.6.0 mail-in-16.arcor-online.net D95B7258334 X-Virus-Scanned: ClamAV 0.94.2/8976/Tue Feb 10 15:04:25 2009 on mail-in-16.arcor-online.net X-Virus-Status: Clean X-Antispam: No, score=0.0/5.0, scanned in 0.067sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200902101240.n1ACemJM025685@sac.sfbay.sun.com> <18833.31489.181789.352638@gargle.gargle.HOWL> Status: RO Content-Length: 1863 James Carlson wrote: > Casper Dik writes: > > char *stpcpy(char *restrict s1, const char *restrict s2); > > char *stpncpy(char *restrict s1, const char *restrict s2, size_t n); > > wchar_t *wcpcpy(wchar_t restrict *ws1, const wchar_t *restrict ws2); > > wchar_t *wcpncpy(wchar_t restrict *ws1, const wchar_t *restrict ws2, size_t > > n); > > The lint maintainers be notified so that they can add stpcpy and > wcpcpy to their list of security-questionable functions warned about > via -errsecurity. (At least file an RFE.) Erm... are both |strcpy()| and |strcat()| in this list, too ? > This looks to me like a standards-related blunder. "stpncpy" and > "wcpncpy" functionality (strncpy-like zero pad to end of the buffer, > *and* leaving full destination buffers unterminated) doesn't seem to > make much sense in this context. My primary interest was |stpcpy()| to get performance of the locale codepaths fixed (we assume that we check at the _beginning_ that all allocated buffers have sufficient size (since the use of something like |stplcpy()| would completely kill the performance advantage since more registers and more operations are required for string copies)). Right now these codepaths are seveal _factors_ (more than 2x) _slower_ than on Linux and one of the primary "root cause" is the over-use of inefficient buffer handling (whic hwe try to partially address with the use of |stpcpy()|). > I think it's a shame they didn't do stplcpy and wcplcpy instead. Do > we have anyone involved in the standards process who could add > comments? Don Cragun was RIF'ed and right now I don't know anyone at Sun who can be queried for standards issues. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From Joerg.Schilling@fokus.fraunhofer.de Tue Feb 10 08:35:41 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1AGZfJD025670 for ; Tue, 10 Feb 2009 08:35:41 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1AGZdew005236 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 10 Feb 2009 08:35:41 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KEU00105ZFHXI00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Feb 2009 09:35:41 -0700 (MST) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEU00ANTZFF6GE0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Feb 2009 09:35:40 -0700 (MST) Received: from relay44i.sun.com ([192.5.209.118]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1AGWlpm027836 for ; Tue, 10 Feb 2009 16:35:39 +0000 (GMT) Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay44i.sun.com with ESMTP id BT-MMP-1068916 for PSARC-ext@sun.com; Tue, 10 Feb 2009 16:35:39 +0000 (Z) Received: from relay45i.sun.com (relay45i.sun.com [192.5.209.94]) by mms49es.mms.us.syntegra.com with ESMTP id BT-MMP-16691903 for PSARC-ext@sun.com; Tue, 10 Feb 2009 16:35:38 +0000 (Z) Received: from iron02.fraunhofer.de ([153.96.1.56] [153.96.1.56]) by relay4i.sun.com with ESMTP id BT-MMP-7921078 for PSARC-ext@sun.com; Tue, 10 Feb 2009 16:35:38 +0000 (Z) Received: from pluto.fokus.fraunhofer.de ([195.37.77.164]) by iron02.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-SHA; Tue, 10 Feb 2009 17:35:38 +0100 Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id n1AGZbTB013671; Tue, 10 Feb 2009 17:35:37 +0100 (MET) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Feb 2009 17:35:37 +0100 Date: Tue, 10 Feb 2009 17:35:34 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: stpcpy, stpncpy, wcpcpy, wcpncpy in lib C [PSARC/2009/084 Self Review] In-reply-to: <200902101240.n1ACemJM025685@sac.sfbay.sun.com> To: PSARC-ext@sun.com, casper@sac.sfbay.sun.com Message-id: <4991acd6.OYFUYYUiAYxeW2gx%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.440sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200902101240.n1ACemJM025685@sac.sfbay.sun.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 10 Feb 2009 16:35:37.0804 (UTC) FILETIME=[9AAEC0C0:01C98B9D] Status: RO Content-Length: 1280 Casper Dik wrote: > 2. Discussion > > Linux, the various BSD operating systems and now IEEE Std 1003.1-2008 > provide the { |stpcpy()|, |stpncpy()|, |wcpcpy()|, |wcpncpy()| }-family > of functions. These behave similar as the |str*cpy()|/|wcs*cpy()| > family of functions, except that they return a pointer to the _end_ > of the buffer instead of the beginning, allowing efficient concaternation > of strings. > > 3. Interface table > > All four functions are "Committed". > > 4. References > > Bugster CR #6793969 RFE: Add |stpcpy| to libc > http://www.opengroup.org/onlinepubs/9699919799/functions/stpcpy.html > http://www.opengroup.org/onlinepubs/9699919799/functions/stpncpy.html > http://www.opengroup.org/onlinepubs/9699919799/functions/wcpcpy.html > http://www.opengroup.org/onlinepubs/9699919799/functions/wcpncpy.html Interesting.... these functions do not appear in the POSIX.1-2008 alphabetical index. 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 Scott.Rotondo@sun.com Tue Feb 10 10:30:33 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1AIUXWI003521 for ; Tue, 10 Feb 2009 10:30:33 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1AIUTCX008324 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 10 Feb 2009 11:30:32 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KEV00M3X4QW1F00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Feb 2009 10:30:32 -0800 (PST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEV00KI74QTZ810@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Feb 2009 10:30:29 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1AIUTXb002546 for ; Tue, 10 Feb 2009 18:30:29 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KEV00A004B1LC00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Feb 2009 11:30:29 -0700 (MST) Received: from [129.146.108.62] ([unknown] [129.146.108.62]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KEV00M764QQH0G0@mail-amer.sun.com>; Tue, 10 Feb 2009 11:30:26 -0700 (MST) Date: Tue, 10 Feb 2009 10:30:26 -0800 From: Scott Rotondo Subject: Re: stpcpy, stpncpy, wcpcpy, wcpncpy in lib C [PSARC/2009/084 Self Review] In-reply-to: <18833.31489.181789.352638@gargle.gargle.HOWL> Sender: Scott.Rotondo@sun.com To: James Carlson Cc: Casper Dik , PSARC-ext@sun.com, roland.mainz@nrubsig.org Message-id: <4991C7C2.1040708@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200902101240.n1ACemJM025685@sac.sfbay.sun.com> <18833.31489.181789.352638@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.12 (X11/20080422) Status: RO Content-Length: 772 James Carlson wrote: > Casper Dik writes: >> char *stpcpy(char *restrict s1, const char *restrict s2); >> char *stpncpy(char *restrict s1, const char *restrict s2, size_t n); >> wchar_t *wcpcpy(wchar_t restrict *ws1, const wchar_t *restrict ws2); >> wchar_t *wcpncpy(wchar_t restrict *ws1, const wchar_t *restrict ws2, size_t >> n); > > The lint maintainers be notified so that they can add stpcpy and > wcpcpy to their list of security-questionable functions warned about > via -errsecurity. (At least file an RFE.) That RFE should be filed under compilers-tools/c/lint and refer to CR 4877995. Scott -- Scott Rotondo Principal Engineer, Solaris Security Technologies President, Trusted Computing Group Phone/FAX: +1 408 850 3655 (Internal x68278)