[PATCH] uqmi: fix compilation with GCC12
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
>> GCC complains about this code because the pointer is only removed
>> if (req->complete == &complete)
>> req->complete = NULL;
>> 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.
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.
More information about the openwrt-devel