Re: [PATCH] strcat.3: SYNOPSIS: Fix the size of 'dest'

[Russ Allbery <eagle@eyrie.org>]

Alejandro Colomar via Libc-alpha <libc-alpha@sourceware.org> writes:

> I'm continuing my indiscriminated shooting against broken functions.
> I don't remember if I ever used it, but it got me surprised for how much
> broken it is.

> Please kill this function in glibc.  The updated prototype using a bit
> of imagination to overextend VLA syntax to show how it behaves, shows
> how broken it is.

> It is impossible to use this function correctly (okay, it you try hard,
> you can, but only for the pleasure of using it without crashing, not for
> anything useful).

Hi Alejandro,

I'm just a bystander here, but I've seen a few proposals like this go by,
and I'm not sure anyone has yet said explicitly that these functions are
incredibly widely used in real C code out in the world.  They predate all
of the functions that you are recommending as replacements for them, so
they're common in old, portable C.

I think the work you're doing to document that they should never be used
for new code in the man pages is great; please continue!  Although it may
be useful to carry with that some caveats about portability; some of the
replacements you've mentioned are going to pose portability challenges.

I'm a bit more dubious about glibc marking these functions as formally
deprecated unless the C standard also deprecates them (as happened with
gets, which is probably the best precedent for what you're trying to
accomplish).

For the record, there is quite a lot of code out there that uses strcpy
and strcat safely, using a pattern where first the total length of the
resulting string is calculated, that much space is allocated, and then it
is assembled with strcpy and strcat.  This used to be the standard way to
assemble strings in C before strlcpy or asprintf existed (and neither of
those functions are all that portable even now; I would still hesittate to
use either without a configure probe and a replacement implementation).  I
think you're exaggerating the difficulty of using them safely a tiny bit,
but maybe that's just because I'm an old C programmer for whom that
pattern is a finger macro.

It's also probably worth saying explicitly that strlcpy and strlcat are
still quite dangerous functions and need to be used very carefully.  They
do solve the problem of buffer overflows when used properly, but they
replace that problem with silent truncation, which can also cause security
vulnerabilities in the right circumstances.

-- 
Russ Allbery (eagle@eyrie.org)             <https://www.eyrie.org/~eagle/>