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

[Ryan Long]

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 <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

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