This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Using strlcpy if target OS allows it


On Thu, Apr 21, 2005 at 11:55:34AM -0700, J.T. Conklin wrote:
> Joe Buck <Joe.Buck@synopsys.COM> writes:
> > There appear to be only four calls of strcpy in the library itself
> > (as opposed to the testsuite).  All four take this exact form:
> >
> >       char* __sav = new char[std::strlen(__old) + 1];
> >       std::strcpy(__sav, __old);
> >
> > Perhaps the V3 maintainers could be persuaded to accept a patch that
> > replaces all four with a call to
> >
> > inline char* __cstring_duplicate(const char* __old) {
> >   unsigned __size = std::strlen(__old) + 1;
> >   char* __sav = new char[__size];
> >   return std::strcpy(__sav, __old);
> > }
> >
> > This would have maintainance advantages, as four identical code sequences
> > become one.
> 
> If a change is made, why not replace the strcpy() with a memcpy()?  As
> it is, strcpy() is copying until it reaches the terminating null char,
> even though we already know how many bytes to copy.  memcpy() is often
> more efficent than strcpy as well, even those implementations that go
> to Herculean efforts to do only word-aligned read/writes.

Good point.  That would be a small (probably negligle) performance
improvement and would get rid of the need to patch OpenBSD (other than the
test suite issue).  Perhaps some interested party would like to make a patch?




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]