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