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?
Do the rest of the patches in this set look good?
Chris
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
