That's a non-problem

Posted May 20, 2009 18:38 UTC (Wed) by elanthis (guest, #6227)
In reply to: That's a non-problem by smurf
Parent article: EGLIBC: Not a fork, but a glibc distribution

And by that argument, including strlcpy() is pointless because any app wanting to use it already includes a copy of it.

Including strlcpy() in eglibc will do Linux application developers no more good than its inclusion into BSD libc. You still won't be able to use it everywhere and you'll still be required to include copies of it. If and when glibc proper supports it (which seems unlikely) then the Linux ecosystem on a larger whole will have it and people can start using it.

It's worth noting that the reasoning against strlcpy() is relatively valid. It isn't actually safe. It protects against buffer overflows, but what you really want to do is check before hand anyway and either error out or allocate a larger buffer, because truncated text in many contexts is just as much of a security issue as a buffer overrun, especially in cases where some kind of validation is done on the string before the copy is made. Even if it's not a security issue, in most cases the user is far better served by an error or warning about the truncated text than he is by just having his data silently cut off. Many people (including Drepper) believe that giving users strlcpy() is going to leave them just as lazy and will just shift software from one problem to another, instead of teaching them to Do It Right(tm) or even better just doing it right in the first place.

It is for that reason that people should consider making use of the glibc asprintf() and the standard strdup() functions instead of the BSD l-style functions.

That's a non-problem

Posted May 20, 2009 18:56 UTC (Wed) by dlang (guest, #313) [Link] (5 responses)

aren't the strlcpy() family of calls included in the latest posix spec?

That's a non-problem

Posted May 20, 2009 22:15 UTC (Wed) by msbrown (guest, #38262) [Link] (3 responses)

No, the strl* family is not in POSIX 2008. They were proposed but rejected since they did not really solve the problem (as pointed out above).

and what would they standardize?

Posted May 21, 2009 4:27 UTC (Thu) by JoeBuck (subscriber, #2330) [Link]

The OpenBSD strlcat has different behavior than the Solaris strlcat, which makes it a problem to use the function in a portable application.

That's a non-problem

Posted May 21, 2009 11:11 UTC (Thu) by ncm (guest, #165) [Link] (1 responses)

We can point to strtok() and gets(), already in POSIX, as interfaces even more stupid than strlcpy(), but that hardly seems like a compelling argument for inclusion.

That's a non-problem

Posted May 21, 2009 17:05 UTC (Thu) by madscientist (subscriber, #16861) [Link]

gets() and strtok() are in POSIX because they're in the ISO C standard runtime library, and POSIX includes the ISO C standard library in its entirety by reference.

That's a non-problem

Posted May 21, 2009 0:11 UTC (Thu) by dododge (guest, #2870) [Link]

ISO/IEC TR 24731-1 adds bounds-checking functions to the Standard C library, but it's still just a draft. The proposed functions use a "_s" suffix with existing function names. The group explicitly rejected the strlcpy name because they want to provide a large consistent suite of these functions in one shot -- not just basic string operations but also things like tmpfile_s, vfprintf_s, asctime_s, wmemcpy_s, and many others. According to the associated Rationale, strcpy_s also performs more checks and has more elaborate error handling than strlcpy.

That's a non-problem

Posted May 21, 2009 10:09 UTC (Thu) by nix (subscriber, #2304) [Link]

Yes indeed. Of course what people then do is use strdup() and forget to check for NULL returns: you'd think 'oh that only leads to a coredump, DoS only', but thanks to structures and arrays it's quite easy to convert a pointer to NULL into a pointer to *anywhere*, so NULL dereferences are often security holes.

C is a nice low-level language but should never be allowed near user data, IMHO. (Now, back to work for me, writing financial stuff in C which spends all its time getting near user data.)

That's a non-problem

Posted May 21, 2009 17:16 UTC (Thu) by spitzak (guest, #4593) [Link] (2 responses)

<i>strlcpy protects against buffer overflows, but what you really want to do is check before hand anyway and either error out or allocate a larger buffer,</i>

You seem to have missed the fact that strlcpy returns the size of the buffer that would be needed. You have a free test to see if the buffer needs to be reallocated. And if not, how about that, the copy is done, and you don't have to do another call!

The arguments againsts strl* are just stupid now. It is pretty obvious that it is what everybody wants.

That's a non-problem

Posted May 22, 2009 11:29 UTC (Fri) by liljencrantz (guest, #28458) [Link] (1 responses)

Speaking as somebody who does occasionally use strlcpy, I'm not sure I agree with that everyone wants strlcpy. The counterargument is that extremely few projects use them, so they would waste memory in the shared library, since they'd likelyu be paged in all the time because they're on the same page as actually _used_ functions. And for no benefit, since very few people use C for direct string manipulation, and those that do perform heavy duty string manipulations use a container library, and not raw C strings.

I don't know if that argument is true, but I did a quick grep of my s?bin-folders (Plain Ubuntu Handy Hardon system), and though there are a few dozen instances of programs that use strlcpy, none of them are running right now on my system, so for me personally, including them _would_ waste memory. Gimp, totem, and sftp uses it, though, and maybe the users of those applications are a majority. I honestly don't know.

That's a non-problem

Posted May 25, 2009 13:41 UTC (Mon) by wawjohn (guest, #509) [Link]

Good thing I had already finished my cup of coffee when I read your OS
version description:

> Plain Ubuntu Handy Hardon system

Got any more 'corrected' names for other Ubuntu releases?