Am 08.03.2016 um 02:34 schrieb Derek Martin: > On Mon, Mar 07, 2016 at 04:30:29PM +0000, Richard Russon wrote: >> This "feature" is small collection of bug fixes. >> Some are from Karel Zak's Notmuch repository; the others are mine. > > Are the changes implemented in the patches documented anywhere? I'm > interested to know more about some of these, as they sound potentially > unsafe or otherwise problematic. For instance: > > [...] >> * Use unlocked libc IO everywhere. > > How do you ensure data integrity of, say, an mbox mailstore if you're > not locking? > >> * Remove TLS version notification > > Is this a violation of the license? > >> * Bye srandom() and random() > > Why? Does Mutt use them in a way that is particularly sensitive to > very long repeating sequences? What do you do instead? > > [...] > >> * add strndup.c strnlen.c > > Why? The standard "n" functions are almost always misused, and > usually introduce more problems than they solve, and should generally > be avoided. Though, if you really need them, the C standard has > provided these two since 2008, and GLIBC, and I'd imagine BSD libc, > for probably considerably longer (though I'm too lazy to actually > look). If your system is running an OS that's older than that, you > should probably set it on fire. =8^)
[...] > These cases are particularly bad because when they happen, the program > appears to work fine but produces wrong behavior *sometimes*, making > it hard to track down. Using strcpy() instead of strncpy() or > strcmp() instead of strncmp() will just crash if the input hasn't been > properly sanitized, which will tell you EXACTLY what's wrong. > Use strlcpy() or strlcat() (but do note that the length parameter is the output buffer size, not the maximum length to copy!), and snatch them from BSD if need be, because Linux's libc doesn't have them.
