bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU Make 4.4.1 fails in a spectacular fashion on NetBSD 10.0 AMD64


From: Paul Smith
Subject: Re: GNU Make 4.4.1 fails in a spectacular fashion on NetBSD 10.0 AMD64
Date: Fri, 19 Apr 2024 13:41:36 -0400
User-agent: Evolution 3.52.0 (by Flathub.org)

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".



reply via email to

[Prev in Thread] Current Thread [Next in Thread]