Hi Martin and Paul,
Thanks for your detailed explanation. I have no further concerns now.
Have a great day ahead!
Best regards,
Haoxin
Paul Smith 于2024年1月21日周日 23:24写道：
> On Sun, 2024-01-21 at 12:00 +0800, Haoxin Tu wrote:
> > May I know if you are planning to propose a fix for it?
f make (make-4.4.0.91
<https://alpha.gnu.org/gnu/make/make-4.4.0.91.tar.gz>).
Please kindly let me know if I can help any further. Thank you all so much
for your time and clarifications again!
Best regards,
Haoxin
Haoxin Tu 于2024年1月21日周日 00:10写道：
> Hi Paul and Martin,
>
> ->
s
>increased after the previous innovation of `get_buffer`), and then the
>execution of `fmtbuf.buffer[need-1] = '\0';`
>
>
> There's a nice catch there - where, in that recursive failure, the writing
> of that terminator overflows a buffer that wasn't actually r
> .
>
> --
> *From:* bug-make-bounces+martin.dorey=hds@gnu.org
> on behalf of Haoxin Tu <
> haoxi...@gmail.com>
> *Sent:* Saturday, January 20, 2024 06:17
> *To:* Paul D. Smith
> *Cc:* Paul D. Smith ; bo...@kolpackov.net <
> bo...@k
Hi,
Thank you so much for your time and reply.
We understand that the entire point of `xrealloc` is never returning 0 to
client users/developers who use this function. However, the issue we
reported here happens when the `xrealloc` internally handles the returned 0
from `realloc` or `malloc` func
