bug-make
[Top][All Lists]
Advanced

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

Re: Segmentation Fault on Exported Resursively Expanded Variable


From: Edward Welbourne
Subject: Re: Segmentation Fault on Exported Resursively Expanded Variable
Date: Wed, 17 Jan 2024 16:19:04 +0000

MIAOW Miao <guoyr_2013@hotmail.com> wrote:
>>>> if ((*ep)[nl] == '=' && strncmp (*ep, v->name, nl) == 0)

Henrik Carlqvist (Tue, 16 Jan 2024 06:59:30 +0000) 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, *ep can be no shorter than having \0 at position nl and
>>> accessing that position should not cause any segfault.

On Tue, 16 Jan 2024 20:53:19 +0200
Eli Zaretskii <eliz@gnu.org> wrote:
>> But it's less efficient when the (*ep)[nl] == '=' test fails.

Henrik Carlqvist (17 January 2024 07:24) wrote:
> Yes, that is true, but to avoid a possible segfault it is necessary to
> somehow check that (*ep)[nl] is a valid address. The current fix at
> https://savannah.gnu.org/bugs/index.php?65172 also works fine, but
> also that fix might be even less efficient as strlen will read every
> char up to and including \0 in *ep.

or, to look at it another way, you can't legally access (*ep)[nl] until
you've looked at every (*ep)[i] for 0 <= i < nl, since if any of those
is '\0' then the memory segment you're allowed to access might end
before (*ep)[nl], making it an invalid memory access.

Henrik's proposed fix Does The Right Thing and is cleaner than the
current proposed fix,

        Eddy.



reply via email to

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