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);
_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers
