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

Chris Johns chrisj at rtems.org
Thu Aug 18 23:07:14 UTC 2022


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

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


More information about the devel mailing list