[PATCH] uqmi: fix compilation with GCC12

Hauke Mehrtens hauke at hauke-m.de
Thu Sep 29 07:46:40 PDT 2022


On 9/28/22 04:22, Rosen Penev wrote:
> On Sun, Aug 21, 2022 at 7:54 AM Hauke Mehrtens <hauke at hauke-m.de> wrote:
>>
>> On 6/11/22 16:47, Bjørn Mork wrote:
>>> e9hack <e9hack at gmail.com> writes:
>>>
>>>> The 'dangling pointer' issue can be fix without using malloc().
>>>>
>>>> --- a/dev.c  2022-05-04 02:18:17.000000000 +0200
>>>> +++ b/dev.c  2022-06-11 08:48:21.185567953 +0200
>>>> @@ -206,6 +206,7 @@ void qmi_request_cancel(struct qmi_dev *
>>>>    int qmi_request_wait(struct qmi_dev *qmi, struct qmi_request *req)
>>>>    {
>>>>       bool complete = false;
>>>> +    bool *c;
>>>>       bool cancelled;
>>>>       if (!req->pending)
>>>> @@ -226,8 +227,10 @@ int qmi_request_wait(struct qmi_dev *qmi
>>>>               uloop_cancelled = cancelled;
>>>>       }
>>>>    -  if (req->complete == &complete)
>>>> -            req->complete = NULL;
>>>> +    c = req->complete;
>>>> +    req->complete = NULL;
>>>> +    if (c != &complete)
>>>> +            req->complete = c;
>>>>       return req->ret;
>>>>    }
>>>
>>> How about just fixing GCC instead?  Having all sorts of funny and
>>> pointless code just to avoid bogus compiler warnings is kind of stupid,
>>> isn't it?
>>>
>>> If GCC can't do better that this, then it's much better to disable that
>>> warning.
>>
>> GCC complains about this code because the pointer is only removed
>> conditionally
>> -------------------------------------------
>>          if (req->complete == &complete)
>>                  req->complete = NULL;
>> -------------------------------------------
>> https://git.openwrt.org/?p=project/uqmi.git;a=blob;f=dev.c;h=bd1020790f844fd364fd753135acd8f53f34d996;hb=HEAD#l229
>>
>> When you make this part unconditionally it does not complain any more.
>>
>> Is it possible that something changes the req->complete pointer address
>> in between?
> this is still an issue.
>>
>> Hauke
Hi,

Is it possible to deactivate the error and make it only a warning which 
we can ignore?
I would deactivate this error for the complete application and add a 
comment to it that this is a workaround for GCC 12.

Did someone create a ticket at GCC for this problem? I am aware of the 
one for elfutils only.

Hauke



More information about the openwrt-devel mailing list