[Crash-utility] [PATCH 2/4] Fix gcc-11 compilation warning on symbols.c

[lijiang]

On Tue, Jul 26, 2022 at 4:55 PM HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab at nec.com>
wrote:

> On 2022/07/26 17:06, lijiang wrote:
> > On Tue, Jul 26, 2022 at 3:24 PM HAGIO KAZUHITO(萩尾 一仁) <
> k-hagio-ab at nec.com>
> > wrote:
> >
> >> On 2022/07/26 15:52, lijiang wrote:>>>> Without the patch, the following
> >> gcc-11 compliation warning is emitted
> >>>>>> for symbols.c:
> >>>>>>
> >>>>>> symbols.c: In function 'cmd_p':
> >>>>>> symbols.c:7412:38: warning: writing 1 byte into a region of size 0
> >>>>>> [-Wstringop-overflow=]
> >>>>>>     7412 |                         *(cpuspec-1) = ':';
> >>>>>>          |                         ~~~~~~~~~~~~~^~~~~
> >>>>>>
> >>>>>
> >>>>>
> >>>>> I have one question about it:
> >>>>> This issue only appears in gcc-11 and earlier, I tested it with
> gcc-12,
> >>>> but
> >>>>> it disappeared. It's interesting.
> >>>> I think that the warning is a false detection.  This patch has no
> >> behavior
> >>>> change, just a cosmetic change to avoid the warning.  I'm not sure,
> but
> >> it
> >>>> might be a gcc bug and fixed in gcc-12.
> >>>>
> >>>
> >>> Probably.  Let's leave it there, if it still appears in the future, we
> >> can
> >>> pick it up. Any thoughts?
> >>
> >> um, I see the warning on RHEL9, what is your concern about fixing this?
> >>
> >
> > If it is not a real issue, we may not need to apply additional patches.
>
> Got it, thanks.
> It's true that it is not crash's fault, but the warning itself is noisy and
> might weaken our attention to new warnings.  So I would like to suppress it
> as far as we can, if a fix is not troublesome.
>
>
Thank you for the explanation, Kazu.


> >
> > I think it's not bad to suppress this for users/distros using gcc-11,
> >> with the small cosmetic change, not harmful.
> >>
> >
> > However, I can help to ack this one, if you would like to have it.
>
> Thanks, Yes please.
>

Ack for this patch.

Thanks.
Lianbo


>
> Kazu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20220727/cc0fdec3/attachment.htm>