strlcpy()

Posted May 30, 2003 14:59 UTC (Fri) by eh (guest, #266) [Link]

Well, thanks for the link, but I almost wish I hadn't asked.
Now sickened early in the morning, waiting for beer o'clock.

> Ulrich Drepper replies scathingly...

... and inappropriately, even idiotically.

sentence 1: claims inefficiency, contradicting Usenix paper cited by
Hellwig, does not support claim.
sentence 2: claims strl*() lead to ``other errors'', again unsupported.
sentence 3: On the soapbox with disregard for real world and the problem
strl*() are meant to address.

Next, in reply to Hellwig's reply to his first reply he reveals the One True:

*((char *) mempcpy (dst, src, n)) = '\0';

He doesn't say whether n is sizeof(*dst)-1, or strlen(src), but either way
this must be preceded by setup and error-checking code. The former
needs n >= strlen(src) or the copy is potentially truncated. So either way
previous error-prone code is necessary, a strlen() is necessary (he argued
efficiency), and you wind up with the elements necessary for plain old
strcpy() (stpcpy() if you're saving the return). So what does mempcpy()
do that's better than strlcpy()?

Next muddled paragraph suggests strl*() are buggy because ``If a string is
too long for an allocated memory block the copying must not simply
silently stop.'' He seems to have missed that his mempcpy() thingy will
``simply silently stop'' and requires advance knowledge of strlen(src)
whereas the return from strlcpy() eases truncation detection which
subsequent code can then handle.

I don't know why I bothered writing this. I'm annoyed now. There's a reason
I usually just lurk.

I don't read the list and don't know Ulrich Drepper's character. I only hope
he just had a bad day. That was 08/2000, maybe someone should bring
the subject up again. (Now someone will say it's been brought up again
and he maintains the same arguments, right?)

(To counteract the tone of this posting I want to say I really admire glibc and
its developers.)