Poettering: The Biggest Myths

Posted Jan 27, 2013 13:00 UTC (Sun) by ovitters (guest, #27950)
In reply to: Poettering: The Biggest Myths by prometheanfire
Parent article: Poettering: The Biggest Myths

That would be nice, but systemd uses lots of (kernel) features that are not available on *BSD. I also don't see *BSD using software that is not BSD licensed. At least that is what I understood from that OpenBSD developer who complained about GNU tools being different and that standards are updated to include those GNU features. If something like 'sed' is a problem, I doubt that relying on a non-GPL init system is acceptable.

Poettering: The Biggest Myths

Posted Jan 27, 2013 16:40 UTC (Sun) by smurf (subscriber, #17840) [Link] (4 responses)

Perhaps those features just make sense, and they complain because they didn't think of them first?

Anyway, nothing prevents them from implementing what's missing on their side.

In related news, *bsd came up with strlcpy(). Do we go to them and complain that it's non-standard? No, we go to our libc maintainer and complain that he doesn't want to include that in the standard library.

I see a fundamental asymmetry here. Which might just be part of the reason there are >=3 BSDs out there, but just one single Linux. :-P

Poettering: The Biggest Myths

Posted Jan 28, 2013 1:05 UTC (Mon) by mezcalero (subscriber, #45103) [Link] (3 responses)

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.

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] (1 responses)

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 (guest, #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.