[PATCH v1 09/12] malloctest/init.c: Added pragmas to address gcc 12 warnings

[Chris Johns]

On 17/8/2022 12:16 pm, Joel Sherrill wrote:
> On Tue, Aug 16, 2022, 6:07 PM Chris Johns <chrisj at rtems.org
> <mailto:chrisj at 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