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 Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
