On Tue, 13 Aug 2013 22:10:22 +0200 Lionel Cons 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? strncpy() only does the last '\0' if the len arg allows I don't know where the "fill with '\0's" came from but it seems detrimental especially if there are many stpncpy() calls in a chain I don't know if there is an alternative _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
