Re: [bug #64551] Possible null pointer dereference on the function get_buffer

* the issue exists ... [in] the newest version To show that, you'd need to show get_buffer being reentered during the xrealloc call. That code is still as it was: https://github.com/mirror/make/blob/master/src/output.c#L395 static char * get_buffer (size_t need) { if (need > fmtbuf.size)

Re: [bug #64551] Possible null pointer dereference on the function get_buffer

Hi all, May I know if you are planning to propose a fix for it? I checked the implementations of other `make` versions a bit further, and as far as I can tell, the issue exists from the older make-4.0.90 (2014-9-30) to the newest version of make

Re: New conditional assignment facility

On Thu, Jan 11, 2024 at 7:55 AM Paul Smith wrote: > So the new confusion becomes, what happens if you use "+" to append to > an existing variable that has a different type? > > Due to decades of history (and, to be honest, significant technical > incentive), we have to say that in this case: > >

[bug #64822] Fix appending to a pattern specific variable.

Follow-up Comment #6, bug#64822 (group make): Tested on linux, sunos and aix, 64 and 32 bits. ___ Reply to this item at: ___ Message sent via Savannah h

[bug #64822] Fix appending to a pattern specific variable.

Follow-up Comment #5, bug#64822 (group make): Paul, i attached fix2 and test2. fix2 is split into 2 parts to ease review. Should be applied in order part1 before part2. Thanks for review. ___ Reply to this item at:

[bug #64822] Fix appending to a pattern specific variable.

Additional Item Attachment, bug#64822 (group make): File name: sv64822_fix2_part1.diffSize:9 KB File name: sv64822_test2.diff Size:9 KB

Re: [bug #64551] Possible null pointer dereference on the function get_buffer

Hi Paul and Martin, ->We know that OUT_OF_MEM() never returns. So there's no way this function can return 0. I totally agree with you all that the function `xrealloc` itself can never return 0. ->It will, as Martin suggests, recurse infinitely (one assumes) because fatal() calls xrealloc() agai

Re: [bug #64551] Possible null pointer dereference on the function get_buffer

* the link you provided seems old Indeed, but that's because, as Paul noted, you're testing code that's even older. * `fmtbuf.size`, defined in ..., was increased after the previous innovation of `get_buffer`), and then the execut

Re: [bug #64551] Possible null pointer dereference on the function get_buffer

On Sat, 2024-01-20 at 23:37 +0800, Haoxin Tu wrote: > But I don't understand why the second invocation of `xrealloc` can > not return zero, I apologize for any imprecise information I provided > in the previous emails. Because of what I said in my original reply: > the entire point of xrealloc is

Re: [bug #64551] Possible null pointer dereference on the function get_buffer

Hi Martin, Thanks for your speedy reply and clarifications. But I don't understand why the second invocation of `xrealloc` can not return zero, I apologize for any imprecise information I provided in the previous emails. >From my understanding, once the second the `xrealloc` is invocated, there

Re: [bug #64551] Possible null pointer dereference on the function get_buffer

* once the second invocation of `xrealloc` ... returns zero But it doesn't, it just recurses, calls get_buffer again, again likely fails and recurses still further until the stack is blown. Or it did until https://git.savannah.gnu.org/cgit/make.git/commit/?id=68be4f74fce91b76e5915449268d6b5

Re: [bug #64551] Possible null pointer dereference on the function get_buffer

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