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: Dennis Clarke
Subject: Re: GNU Make 4.4.1 fails in a spectacular fashion on NetBSD 10.0 AMD64
Date: Sat, 20 Apr 2024 03:41:32 -0400
User-agent: Mozilla Thunderbird

On 4/19/24 15:15, Paul Smith wrote:
On Fri, 2024-04-19 at 14:38 -0400, Dmitry Goncharov wrote:
On Fri, Apr 19, 2024 at 1:42 PM Paul Smith <psmith@gnu.org> wrote:
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.

Dennis, do you see an alternative that is at least equally efficient,
simple and portable?  One alternative that is equally efficient and
simple is variable length arrays.  However, there is a question about
portability of vla vs alloca.

VLAs are strictly less powerful than alloca because alloca() is scoped
to the function, while VLAs are scoped to the enclosing block.  That is
a serious flaw in VLAs and means that it is impossible for them to
replace alloca() in many simple, obvious situations.

In addition, while alloca() is best implemented by the compiler it IS
possible to provide a standards-conforming implementation of them
(which is less performant than a compiler-provided alloca(), but which
works) which means that alloca() is more portable than VLAs, which will
cause compiler errors in any compiler that doesn't support them.

So, I have zero interest in VLAs.  In my opinion they were a mistake
from the first and should never have been implemented or standardized.
I did share this opinion and provided examples of how limiting and
limited they were back when they were being considered for
standardization but, well, it didn't matter.



    Just a reply to let you know I am thinking on this.

    Have been pondering it for quite a while and will likely give this
    some real thought.

    That means a lot more than just "cut and paste".

    We surely agree in that regard.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken




reply via email to

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