Alejandro Colomar via Libc-alpha <libc-alpha@xxxxxxxxxxxxxx> 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@xxxxxxxxx) <https://www.eyrie.org/~eagle/>
