| |||||||||||||
|
| |||||||||||||
strlcpy()strlcpy()Posted May 29, 2003 17:05 UTC (Thu) by cpeterso (subscriber, #305)In reply to: strlcpy() by eh Parent article: strlcpy() I agree that glibc should add these functions. *BSD has had them for years. I think even the Solaris libc has them. I think glibc should go a step further and actually remove the dangerous functions like strcpy(). There are safe replacements. glibc should use a carrot and stick approach. Offer the safe replacements and remove (or just deprecate) the dangerous functions.
(Log in to post comments)
strlcpy() Posted May 29, 2003 17:40 UTC (Thu) by Ross (subscriber, #4065) [Link] There are many perfectly valid uses of strcpy(). In fact most usesof strcpy() are probably correct. Removing that function would lead to huge problems with backwards compatibility, cross-platform portability, and standards compliance. It would be a very, very bad idea. Feel free to use strlcpy() exclusively yourself, but don't tell everyone
strlcpy() Posted May 29, 2003 19:54 UTC (Thu) by dwheeler (guest, #1216) [Link] Yes, strlcpy() is in the *BSDs, it's also in Sun Solaris. It's also in the library Glib (NOT glibc), the basic library for GTK+ and GNOME.However, it is NOT in glibc, because Ulrich Drepper doesn't want it in there. You can see his rationale for this in the glibc mailing list. I don't agree with his decision. One of the biggest security problems is STILL buffer overflows, and strlcpy()/strlcat() can really help reduce their incidence. And since it's not in glibc, everyone has to "roll their own" implementation (which may not be as efficient as it would be if it were in the standard library). If a future C standard included strlcpy() in the standard C library, then I believe glibc would add it too. Thus, if you want strlcpy() available everywhere, it might be best to appear to the ISO C group to add strlcpy() and strlcat() to the C standard library.
strlcpy() Posted May 29, 2003 23:14 UTC (Thu) by eh (guest, #266) [Link] I grabbed libc-hacker-*.bz2 fromftp://sources.redhat.com/pub/glibc/mail-archives/ and grepped neither strlcpy or strlcat. What was his rationale? > If a future C standard included strlcpy() in the standard C library, I certainly hope you're right about that. > [...] it might be best to appear to the ISO C group to add strlcpy() Yes, provided s/\(appea\)r/\1l/ ;)
strlcpy() Posted May 30, 2003 4:52 UTC (Fri) by rloomans (subscriber, #759) [Link] > What was his rationale? The thread starts here. Christoph Hellwig posted a patch to implement strlcat() and strlcpy(). Ulrich Drepper replies scathingly...
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.)
|
|
||||||||||||