On Tue, 13 Aug 2013 23:43:08 +0200 Roland Mainz wrote: > On Tue, Aug 13, 2013 at 11:15 PM, Glenn Fowler <[email protected]> wrote: > > On Tue, 13 Aug 2013 17:11:04 -0400 Glenn Fowler wrote: > >> On Tue, 13 Aug 2013 22:55:33 +0200 Roland Mainz wrote: > >> > 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 ? > > > >> that's what strcopy()/strncopy() do and that's why strncopy() will stay in > >> use > > > >> the 0 fill semantic is bizarre > >> maybe useful in crypto code but certainly bad for > > > >> char buf[1024]; > >> char* b = buf; > > > >> b = stpcpy(b, x, &buf[sizeof(buf)] - b); > >> b = stpcpy(b, y, &buf[sizeof(buf)] - b); > >> b = stpcpy(b, z, &buf[sizeof(buf)] - b); > > > > rats -- stpcpy => stpncpy above
> Mhhh... |strlcpy()| is nearthe thing we may want... except that it > returns a |size_t| and not a pointer to the '\0' string: > -- snip -- right, I looked at that too since libast emulates that too _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
