Re: Implement C11 annex K?

[Rich Felker <dalias at libc dot org>]

On Fri, Aug 15, 2014 at 12:14:21PM -0400, David A. Wheeler wrote:
> On Fri, 15 Aug 2014 08:35:52 -0700, Paul Eggert <eggert@cs.ucla.edu> wrote:
> >   Other techniques should be used for fixed-size buffers.  For reasons 
> > that should be obvious I don't recommend the technique of silent 
> > truncation; but applications that require it can use snprintf, which is 
> > more portable and useful than strlcpy anyway.
> 
> snprintf is overcomplicated for simple string copying (a common operation)

One extra argument of "%s" is not really over-complicated. I'll grant
one thing: having the return value with type int rather than size_t is
mildly problematic, in that snprintf can't be fully equivalent to
strlcpy or strncpy_s, but in cases where the input string is >2GB
you'd probably prefer to have an error rather than processing an
unbounded amount of input, as it's almost surely malicious. If your
data is really potentially that large, C strings are not the proper
format for it.

> and does not directly support concatenation.

Agreed, but concatenation without storing a "current position" between
operations is bad anyway (see: Schlemiel the painter). Still I agree
with you that this makes it hard to fix existing broken code using
only snprintf, and in fact it's dangerous when people try because they
do idiotic things that invoke UB like:

snprintf(buf, size, "%s%s", buf, foo);

> The presence of a formatting string when it's unnecessary is a serious problem;
> a common mistake is to allow attackers to control a formatting string.

Only if two conditions are met: (1) the programmer is a complete
idiot, and (2) you don't have compiler warnings to catch this usage.
Calling a printf-family function with a non-literal format string and
no variadic arguments is almost always an error, and that's why we
have warning options to flag it.

> No formatting string means no opportunity for that mistake.
> There's also the overhead (admittedly slight) of passing and processing the formatting string.

Actually it's a fairly heavy overhead; for small strings it certainly
dominates the runtime of the whole operation.

> Many people who are trying to write secure software in C (such as the OpenBSD and Microsoft folks)
> are increasingly trying to *stop* the use of traditional functions like strcpy and strncpy,

I reject the claim that MS's interest in stopping the use of these
traditional functions has anything to do with security. It's obvious
from the number of functions they "deprecated" and "replaced" with *_s
functions where there was no "security problem" with the original
function, and where the *_s function has so many arguments that it's
easy to misuse, that the intent was never security, and my view is
that it was always to undermine portability and fragment C as a
language. I think MS's continual interference in the C standards
process while they simultaneously refuse to implement any version of
the standard newer than the 1989 version supports this view of their
motives.

Rich