Citing Marco again, concerning strlcpy, because this is even more relevant: > And now if the userspace people in linux would also adopt it the world > would be a better place. Can anyone say glibc?
Actually, there is one additional paper on that web site: http://people.redhat.com/drepper/defprogramming.pdf Ulrich Drepper: "Defensive Programming" (May 3, 2006) The first main chapter, "Safe Programming", starts out like this: Ulrich Drepper writes: > The main problem with programming in C, C++, and similar languages is > the memory handling. Memory for most interfaces has to be allocated > explicitly and this means possibilities for bugs. These memory > handling problems are pervasive and in the last few years have become > the main reason for exploits. A large array of techniques has been > developed by the black hat groups to exploit memory handling bugs. > These bugs mainly include buffer overruns, double free() calls, and > invalid pointer value usage. In later sections we will discuss how to > detect these kind of bugs. Here we concentrate on ways to avoid them > altogether. That does sound promising, doesn't it? In the following, i did find warnings that gets(3) will overflow buffers (surprise, surprise). The function strcpy(3) is are also mentioned: In one example, it is used to correctly copy a string literal into a fixed-size buffer of sufficient size. At that point, i could not find any hint that other uses of this function might be dangerous. But later on, strcpy(3) is used as an example to illustrate the _FORTIFY_SOURCE compiler macro implementing the following check in gcc version 4 (sic): "Functions operating on memory blocks are checked if the size of the memory blocks is known. Not all calls to these functions are checked. This is not possible since in general there is no information about the buffers available." When the new macro is switched on, that is; as far as i understand, in gcc 4, it will be off by default. That's really a tremendous step forward, isn't it? Apart from that, i couldn't find references to strncpy(3) or strncat(3). In particular, i could not find any hint that those two might be used in order to avoid any dangers resulting from strcpy(3) or strcat(3), or that they might even introduce new dangers. I failed to find any evidence that Drepper was aware of the existence of strlcpy(3) or strlcat(3) when he last revised his paper on "Defensive Programming" on May 3, 2006. Sadly, strlcpy(3) states: The strlcpy() and strlcat() functions first appeared in OpenBSD 2.4. By the way, they do have strndup, strdupa and strndupa besides strdup in glibc. Drepper spends more than half a column discussing those four functions. That alone looks rather bizarre - Dowd/McDonald/Schuh, by contrast, elaborate on strcpy, strcat, strlcpy, strlcat filling more than four pages, but apparently don't feel the need to even mention strdup. Drepper does not mention which of the str*dup*s, if any, are portable. He does not mention that alloca(3) is machine dependent, he does not mention that its implementation might be buggy on some systems, he does not mention that use of alloca(3) might fail inside the argument list of a function call, he does not mention that alloca(3) might overflow the stack. He doesn't warn against using strdupa on huge buffers. He only says that alloca(3) is bound to the stack frame, is faster than malloc(3) and releasing the memory could sometimes cause problems when variable size arrays are in use in the same function. So, that appears to be part of the current state of "Defensive Programming for Red Hat Enterprise Linux", straight from glibc horse's mouth...
