On Thu, Sep 29, 2022 at 7:45 AM Hauke Mehrtens <ha...@hauke-m.de> wrote:
>
> On 9/28/22 04:22, Rosen Penev wrote:
> > On Sun, Aug 21, 2022 at 7:54 AM Hauke Mehrtens <ha...@hauke-m.de> wrote:
> >>
> >> On 6/11/22 16:47, Bjørn Mork wrote:
> >>> e9hack <e9h...@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.
What's wrong with working around it? It's not difficult.
>
> Hauke
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
