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