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() again, and malloc() will return 0, so it will call fatal(), which calls xrealloc() again, and malloc will return 0, so it will call fatal(), etc. etc.--this is what I meant by my imprecise comment "infinite loop" I should have said "infinite recursion". Yeah, I also agree with your explanation here for the normal scenario, but the potential error I reported here is the situation: fatal() calls xrealloc() again, and malloc() will return 0, so it will call fatal(), which DOES NOT calls xrealloc() again but directly dereferences the pointer, then leading to the error. ->There's a nice catch there - where, in that recursive failure, the writing of that terminator overflows a buffer that wasn't actually reallocated yet. Yeah, hope I made my points clear now. Thank you all so much again. Best regards, Haoxin Martin Dorey <martin.do...@hitachivantara.com> 于2024年1月21日周日 00:02写道： > > - 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 . > <https://github.com/mirror/make/blob/4.2/output.c#L593>.., was > 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 reallocated yet. > > ------------------------------ > *From:* Paul Smith <psm...@gnu.org> > *Sent:* Saturday, January 20, 2024 07:51 > *To:* Haoxin Tu <haoxi...@gmail.com>; Martin Dorey < > martin.do...@hitachivantara.com> > *Cc:* bug-make@gnu.org <bug-make@gnu.org> > *Subject:* Re: [bug #64551] Possible null pointer dereference on the > function get_buffer > > ***** EXTERNAL EMAIL ***** > > 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 that it never returns 0. > > Look at the implementation of xrealloc(): > > void *result = malloc (size ? size : 1); > if (result == 0) > OUT_OF_MEM(); > return result; > > We know that OUT_OF_MEM() never returns. So there's no way this > function can return 0. > > It will, as Martin suggests, recurse infinitely (one assumes) because > fatal() calls xrealloc() again, and malloc() will return 0, so it will > call fatal(), which calls xrealloc() again, and malloc will return 0, > so it will call fatal(), etc. etc.--this is what I meant by my > imprecise comment "infinite loop" I should have said "infinite > recursion". > > As a reminder this is moot: this code has been rewritten and even the > infinite recursion problem was removed from the code back in 2017. > > -- > Paul D. Smith <psm...@gnu.org> Find some GNU make tips at: > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.gnu.org%2F&data=05%7C02%7CMartin.Dorey%40hitachivantara.com%7C64b0e96f7b7a4d9cf0f308dc19cfa672%7C18791e1761594f52a8d4de814ca8284a%7C0%7C0%7C638413626848068646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2CgTubth7nezTPOU76hCwauMdV%2B8cz%2F9415iVpL%2FVe0%3D&reserved=0 > <https://www.gnu.org/> > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmake.mad-scientist.net%2F&data=05%7C02%7CMartin.Dorey%40hitachivantara.com%7C64b0e96f7b7a4d9cf0f308dc19cfa672%7C18791e1761594f52a8d4de814ca8284a%7C0%7C0%7C638413626848074885%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=0jGEsG8MYYh26rgSn2n8dPl1eydBrKFvkzD0UqnvbuY%3D&reserved=0 > <http://make.mad-scientist.net/> > "Please remain calm...I may be mad, but I am a professional." --Mad > Scientist >
