On Fri, 2024-04-19 at 13:15 -0400, Dennis Clarke wrote: > Yep. The calls to alloca() seem to be all over the place in the code > base and I can not figure out why anyone would want a non-portable > and non-standard thing like that but here we are.
alloca() has been used in the GNU Make code ever since the earliest days in the 1980's. Some of these concerns in the man page are only partly relevant: GNU Make comes with its own working implementation of alloca() which it will use if the compiler doesn't support it. This is tested regularly so we know it works. Unfortunately in your situation the configure script detected that your system DID support alloca, so we didn't use our implementation. It seems wrong that NetBSD provides a broken implementation of alloca(). IMO it should either provide a working implementation, or not provide an implementation at all (so that programs like GNU Make will decide to use an alternative). The configure script always assumes that if the system provides a feature, it's the best one to use. Second, GNU Make uses a wrapper around all memory allocation which immediately exits if we fail to obtain memory (e.g., malloc returns NULL) so it's not that much different if we run out of stack space: you'll still crash just in a different way. The main advantages to alloca are twofold: 1) efficiency for small local buffers, which GNU Make uses a lot. 2) simplification of the code because you don't have to track this memory and ensure it's freed regardless of how the function returns. Unfortunately C doesn't have any sort of RAII or destructor facility. I am in no way condoning the use of alloca in general or suggesting that new programs should continue to use it. I would not use the source code for GNU Make as an example of good coding practices in 2024, in any way (except maybe some smaller, more modern parts). But the above is why it works the way it does, and why changing it is not as trivial as "cut and paste".
