This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc 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]

Wish for 2002 - seconded?


I fall under the collection of people that see strncpy() as a major decrease
in performance when buffer sizes are big and strings to copy are small. I
would like to see something like strncpy that does not NUL-pad byte strings,
but writing C functions to do this make those functions much slower than the
versions in Glibc that are hand-written in assembly.

My workaround for this last year was to define a strmaxcpy() macro:


/* like strncpy but doesn't pad with zeroes. n=total buffer size */
#define strmaxcpy(d, s, n) ({ char *_d=d; const char *_s=s; \
                              int _n=n, _len=strlen(_s)+1; \
                              if(_n > 0) { \
                                memcpy(_d, _s, (_len > _n)?_n:_len); \
                                _d[_n-1]='\0'; \
                              } _d; })


This seems to behave like strlcpy, with the added benefit of using the
assembly code for the target architecture for both strlen() and memcpy().

Unfortunately, this process is still slower because the string must be
scanned twice (once for strlen and once during the copy for memcpy).

So yeah, I would like to see a function in Glibc that can do this with the
same or better performance (depending on buffer size) as strncpy, without the
NUL-padding.

Regards,
 Byron

-- 
Byron Stanoszek                         Ph: (330) 644-3059
Systems Programmer                      Fax: (330) 644-8110
Commercial Timesharing Inc.             Email: byron@comtime.com


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