On 19/8/2022 9:02 am, Ryan Long wrote: > On 8/16/2022 10:55 PM, Chris Johns wrote: >> On 17/8/2022 12:16 pm, Joel Sherrill wrote: >>> On Tue, Aug 16, 2022, 6:07 PM Chris Johns <chr...@rtems.org >>> <mailto:chr...@rtems.org>> wrote: >>> On 17/8/2022 6:11 am, Ryan Long wrote: >>> > Fixed four warnings disabled were for "-Wuse-after-free" and one for >>> a >>> > "-Wfree-nonheap-object." >>> >>> Is this a gcc warning bug? If p1 was used to access the memory the >>> warning is >>> right but we are only referencing the address and not the data. It is >>> no >>> different to: >>> >>> void* p = 0x111111111; >>> printf("P is %p\n", p); >>> >>> This is fine and has to be or we could never access any hardware. >>> >>> >>> That example is different I think. Semantically after a call to free, the >>> address is no longer valid for any use. >> Ah yes sorry, I was looking at the wrong spot in the code. It is down at line >> 1531. >> >>> Ensuring you don't call another member >>> of the malloc family is a legitimate way to avoid double frees. >> Yes using the pointer is invalid. >> >>> If we have an issue with a specific use case pattern that GCC is tripping, >>> then >>> we discuss it with them. I'm sure all of these were well thought out. >>> >>> Besides this code is pushing deliberate error conditions so we should not be >>> surprised that the compiler is detecting issues with the code. >> I am not sure the test is correct and should be there. Passing in and then >> testing the same value is returned assumes undefined behaviour: >> >> If ptr does not match a pointer returned earlier by calloc(), malloc(), >> or realloc() or if the space has previously been deallocated by a call >> to free() or realloc(), the behavior is undefined. >> >> https://pubs.opengroup.org/onlinepubs/9699919799/functions/realloc.html > > For some of the tests we would just need to set p1 to NULL before the check > then > right?
I think so but Joel is the person to comment on the tests and standards. > Do the rest of the patches in this set look good? I think so. Some are hard to sort out. I have had a look and then left them. I suppose this is why most are resorting to pragmas to handle. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
