| |||||||||||||
Poettering: The Biggest MythsPoettering: The Biggest MythsPosted Jan 28, 2013 15:59 UTC (Mon) by epa (subscriber, #39769)In reply to: Poettering: The Biggest Myths by mezcalero Parent article: Poettering: The Biggest Myths
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.
(Log in to post comments)
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.
|
|||||||||||||