Re: Implement C11 annex K?

[Rich Felker <dalias at libc dot org>]

On Fri, Aug 15, 2014 at 07:25:51PM -0700, Russ Allbery wrote:
> > My point is that buffer overflows are a serious problem; we need
> > widely-available functions for common cases that are easy to use and
> > make them much less likely.  Also, strlcpy/strlcat were created by
> > OpenBSD to counter buffer overflows, so clearly it's not just Microsoft
> > that see a need for standard easy-to-use functions to counter buffer
> > overflows in fixed-length buffers.
> 
> What generally you get from strlcpy/strlcat is turning buffer overflows
> into truncations (which one can then check for, but which a lot of code
> does not).  I generally agree with you that this is useful for legacy code
> that uses a lot of static buffers.  I also generally agree with Paul that
> static buffers are *themselves* a design flaw that should be avoided, and
> it's not entirely clear to me that it's a good idea to modify code to add
> strlcpy/strlcat and stop there, rather than modifying it to stop using
> static buffers entirely.

If they're really using _static_ storage, that's a design bug, yes.
But in practice they're often using automatic-storage buffers with a
constant size limit. This is rarely a design bug unless the
requirements actually require supporting arbitrary-length data;
continually allocating memory until you OOM is, in practice, a much
bigger design bug.

> And, honestly, if I were working on such legacy code, I would be very
> tempted to use asprintf into a temporary variable to do whatever I want,
> check the total length when finished to see if it will fit, and then
> either return an error or memcpy the results into the static buffer.  That
> doesn't change the calling contract, but gives you many of the safety
> benefits of dynamic allocation.

It does change the calling contract. It changes a function which
cannot fail to a function which has a failure case that it needs to be
able to report to the caller, which is a radically different contract
because now the caller has to check whether it succeeded or failed.

And if you make the function abort the whole program on error (a
common disgusting solution to this problem which a depressing number
of people do) you've still changed the interface contract: now a
function which previously always returned (successfully, no less)
might return or might abort the program.

Rich