User: Password:
Subscribe / Log in / New account

Poettering: The Biggest Myths

Poettering: The Biggest Myths

Posted Jan 28, 2013 1:05 UTC (Mon) by mezcalero (guest, #45103)
In reply to: Poettering: The Biggest Myths by smurf
Parent article: Poettering: The Biggest Myths

Actually, I find the discussion around strlcpy() interesting, because I can actually understand the points Drepper makes about it, and I think I side with him on it on the opinion that it doesn't really lead to better code... (I know for sure at least that I never needed a call like that when hacking on systemd.)

The thing is simply that strlcpy() leads people to use fixed size arrays to store possibly much longer data in it, so they want the truncation. But if you do this, then you tend to hide a problem with it, and instead you should have the checked the length of the argument in the first place and returned an error (after all the general rule is to always check your input!). Implicit truncation without error condition is almost never a good idea. And if you didn't check explicitly for the overly long string, then you should handle that string in its entirety properly, which generally means dynamically allocated memory of the correct size, which still not requires strlcpy().

I do see a valid usecase for some ways to call strncpy() (to fill in fixed size strings in structs where you usually want to zero out the rest of the string), and there's a very useful usecase for strdup() -- but strlcpy(), not so sure.

But, then again, given how trivial the call is, and how many people want it, if I was glibc hacker I'd still merge it... This shouldn't be fought with the fervour that people fight it with.

(Log in to post comments)

Poettering: The Biggest Myths

Posted Jan 28, 2013 10:50 UTC (Mon) by smurf (subscriber, #17840) [Link]

It's in libbsd, so if you want it it's there.

Anyway, strlcpy was intended to be an example of the different styles of handling NIH situations in Linux vs. *BSD land. I didn't exactly intend to trigger yet another strlcpy sub-discussion. ;-)

Poettering: The Biggest Myths

Posted Jan 28, 2013 15:59 UTC (Mon) by epa (subscriber, #39769) [Link]

Unfortunately the kind of programmers who use fixed size arrays will do so with or without strlcpy() being in the standard library. Given that, you might as well provide the tools to do so safely rather than push people towards the more dangerous strcpy(). And there is no harm in a belt-and-braces approach, where you check the length of every input string and return a sensible failure message, but then use strlcpy() and other safe functions *just in case* you accidentally missed a check somewhere. Silently truncating is bad, but it's much the lesser evil compared to a buffer overrun.

Poettering: The Biggest Myths

Posted Jan 28, 2013 19:42 UTC (Mon) by k8to (subscriber, #15413) [Link]

I work on various code written in various styles.

Sometimes I work on code that is assembling various things into buffers in order to generate a representation out-of-program, like on disk or on the wire. These things often work with fixed sized buffers into which they are assembling data, because the data representation has a fixed size.

In this case, changing codepaths to use strlcopy gives SIGNIFICANT improvements in safety. strncpy is not acceptable in these cases because it will incur large performance penalties with the null padding. Yes, we try to have sane and well placed logic to enforce the sizing, but putting the logic in each callsite is just begging for overruns which can be unacceptable in some use cases, so strlcpy gives us some safeguard, despite being careful in the logic.

Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds