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
in the ast usage for strncopy(dst,src,len) len is set to chars-remaining-in(dst)
so that src will not overrun dst
strncopy() always returns a pointer to a trailing '\0' even if len is hit
this is a much handier semantic in the ast usage than stpncpy()
which if someone measured it would probably spends most of its cycles padding
rather than copy'ing
in any event { stpcpy() stpncpy() } are both in ast now
and ast strcopy() usage will incrementally switch to stpcpy()
but ast strncopy() calls will remain for efficiency
_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers
