On Sun, 21 Jan 2024 14:45:00 -0500
Dmitry Goncharov wrote:
> i bet, the purpose of having (*ep)[nl] == '=' check before strncmp was
> to relieve make from running strncmp unless the variables have the
> same length.
Yes, that is also my guess. Unfortunately, it could give a segfault if
(*ep)[nl]
On Tue, Jan 16, 2024 at 1:21 PM Henrik Carlqvist wrote:
>
> On Tue, 16 Jan 2024 06:59:30 +
> MIAOW Miao wrote:
> > if ((*ep)[nl] == '=' && strncmp (*ep, v->name, nl) == 0)
>
> Looking at that line, the rather obvious fix would be to change it to:
>
> if (strncmp (*ep, v->name, nl) == 0 && (*e
MIAOW Miao wrote:
if ((*ep)[nl] == '=' && strncmp (*ep, v->name, nl) == 0)
Henrik Carlqvist (Tue, 16 Jan 2024 06:59:30 +) wrote:
>>> Looking at that line, the rather obvious fix would be to change it to:
>>>
>>> if (strncmp (*ep, v->name, nl) == 0 && (*ep)[nl] == '=')
>>>
>>> That way, *
On Tue, 16 Jan 2024 20:53:19 +0200
Eli Zaretskii wrote:
> From: Henrik Carlqvist
> > On Tue, 16 Jan 2024 06:59:30 +
> > MIAOW Miao wrote:
> > > if ((*ep)[nl] == '=' && strncmp (*ep, v->name, nl) == 0)
> >
> > Looking at that line, the rather obvious fix would be to change it to:
> >
> > if
On Mon, Jan 15, 2024 at 9:02 AM MIAOW Miao wrote:
> Here is a Makefile that can reproduce the segmentation fault:
>
> THIS_LONG_VARIABLE_NAME_PREDUCE_THE_ERROR= $(shell echo hello)
> export THIS_LONG_VARIABLE_NAME_PREDUCE_THE_ERROR
>
> all: ; echo "abc"
Thank you for your report.
A added a fix h
> Date: Tue, 16 Jan 2024 19:21:04 +0100
> From: Henrik Carlqvist
> Cc: psm...@gnu.org, bug-make@gnu.org
>
> On Tue, 16 Jan 2024 06:59:30 +
> MIAOW Miao wrote:
> > if ((*ep)[nl] == '=' && strncmp (*ep, v->name, nl) == 0)
>
> Looking at that line, the rather obvious fix would be to change it
On Tue, 16 Jan 2024 06:59:30 +
MIAOW Miao wrote:
> if ((*ep)[nl] == '=' && strncmp (*ep, v->name, nl) == 0)
Looking at that line, the rather obvious fix would be to change it to:
if (strncmp (*ep, v->name, nl) == 0 && (*ep)[nl] == '=')
That way, *ep can be no shorter than having \0 at posit
On Tue, 2024-01-16 at 06:59 +, MIAOW Miao wrote:
> (gdb) bt
> #0 recursively_expand_for_file (v=v@entry=0xad5740,
> file=file@entry=0x0) at src/expand.c:119
> ...
> #20 0x0041acec in main (argc=, argv= out>, envp=) at src/main.c:2918
This is not as helpful because you've elided the en
On Mon, Jan 15, 2024 at 9:02 AM MIAOW Miao wrote:
> Here is a Makefile that can reproduce the segmentation fault:
>
> THIS_LONG_VARIABLE_NAME_PREDUCE_THE_ERROR= $(shell echo hello)
> export THIS_LONG_VARIABLE_NAME_PREDUCE_THE_ERROR
>
> all: ; echo "abc"
>
> Commands log:
>
> user@fedora:~$ make
>
I was not able to reproduce it with Make 4.1 or Make 4.3.
I don't have the original Make 4.4.1, but I had a binary of my fork 4.4.1h2
from https://github.com/henca/Henriks-make and got a segfault in that one
which probably means that I have been able to reproduce the report from Miao.
Opening a
On Mon, 2024-01-15 at 11:21 +, MIAOW Miao wrote:
> I found name of exported resursively expanded variable with $(shell
> ...) cannot be too long in gnu make version >= 4.4, otherwise a
> segmentation fault is triggled. I'm not sure if variable-name-too-
> long is a bug. However, make is
> suppo
11 matches
Mail list logo
