On Tue, Aug 13, 2013 at 10:10 PM, Lionel Cons <[email protected]> wrote:
> On 13 August 2013 22:05, Glenn Fowler <[email protected]> wrote:
>> On Tue, 13 Aug 2013 21:51:09 +0200 Lionel Cons wrote:
>>> On 13 August 2013 15:54, Glenn Fowler <[email protected]> wrote:
>>> > I looked at this closer and stpncpy() is different from strncopy()
>>> > so unlike
>>> > strcopy() => stpcpy()
>>> > we won't be able to do
>>> > strncopy() => stpncpy()
>>> > ast strncopy() usage is to prevent overflow of the destination string
>>> > so in most cases the size argument is >> strlen(source)
>>> > and in that case stpncpy() will fill the difference with '\0' -- a waste
>>> > unless an app really needs the '\0''s
>>
>>> I think the point of having stpcpy() and stpncpy() in libast is to
>>> provide the new POSIX string functions for old systems. My staff said
>>> there are two advantages in using them:
>>> 1. stpcpy() returns the end of the string, allowing fast
>>> concatenations. Those who think this is no longer necessary should
>>> feel free to benchmark the effects on ARM and ARM64
>> right, that's why we had strcopy()/strncopy() for 20 some years
>>
>>> 2. stpcpy() can be used on all systems with libast, and newer systems
>>> which have libast in libc benefit from hand optimised assembler code
>>> which can be 10 fold faster than the plain C code for longer strings
>>
>>> > without the '\0' fill property the ast usage could be adjusted
>>
>>> Isn't this like the old story of strncpy() adding '\0' at the end of
>>> some platforms and on others don't do it?
>>
>> I don't mind a function adding 1 '\0'
>> but in stpncpy(dst,src,len) if (strlen(src) < len) then it pads with
>> (len-strlen(src)) '\0's
>
> OK.
> What is the rationale behind this behaviour? Does *POSIX* strncpy() do
> the same? Is there an alternative in *POSIX* which doesn't fill the
> string buffer up to <n> all the time?
The POSIX manpage for |strncpy()| says this:
-- snip --
If the array pointed to by s2 is a string that is shorter
than n bytes, null bytes shall be appended to the copy in the array
pointed to by s1, until n bytes in all
are written.
-- snip --
... |stpcpy()| and |stpncpy()| only differ from |strcpy()| and
|strncpy()| that the |stp*()|-functions return a pointer to the '\0'
byte at the end of the C string while the |str*()|-function always
return a pointer to the beginning of the destination buffer. Beyond
that they are AFAIK identical... and that's the only rationale...
IMO the standard should provide |strncpy()|/|stpncpy()| variants which
exactly add '\0' at the requested end of the buffer and not fill the
buffer up to the limit...
... NSPR (Netscape Portable Runtime... used bu Mozilla/Firefox/etc.)
has a |*strcpyz()|:
-- snip --
/*
* PL_strncpyz
*
* Copies the source string into the destination buffer, up to and including
* the trailing '\0' or up but not including the max'th character, whichever
* comes first. It does not (can not) verify that the destination buffer is
* large enough. The destination string is always terminated with a '\0',
* unlike the traditional libc implementation. It returns the "dest" argument.
*
* NOTE: If you call this with a source "abcdefg" and a max of 5, the
* destination will end up with "abcd\0" (i.e., its strlen length will be 4)!
*
* This means you can do this:
*
* char buffer[ SOME_SIZE ];
* PL_strncpyz(buffer, src, sizeof(buffer));
*
* and the result will be properly terminated.
*/
PR_EXTERN(char *)
PL_strncpyz(char *dest, const char *src, PRUint32 max);
-- snip --
... Glenn: Does that help ?
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [email protected]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers
