[PATCH] Fix pedanic warnings without a storage increase
Joel Sherrill
joel at rtems.org
Tue Aug 30 17:45:33 UTC 2022
On Tue, Aug 30, 2022 at 9:40 AM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:
> On 30/08/2022 16:38, Joel Sherrill wrote:
> > + /*
> > + * Ignore these warnings:
> > + *
> > + * - invalid use of structure with flexible array member
> > + *
> > + * - struct has no members
> > + */
> > + #pragma GCC diagnostic push
> > + #pragma GCC diagnostic ignored "-Wpedantic"
> >
> >
> > This is heavy handed. -Warray-bounds should be enough.
>
> There is no array bounds warning. There are only the above two
> -Wpedantic warnings.
>
OK I was suggesting that because -Wzero-length-bounds which should be
the precise warning was turned on by -Warray-bounds.
How about just -Wzero-length-bounds?
-Wzero-length-bounds
Warn about accesses to elements of zero-length array members that might
overlap other members of the same object. Declaring interior zero-length
arrays is discouraged because accesses to them are undefined. See See Zero
Length
<https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Zero-Length.html#Zero-Length>
.
For example, the first two stores in function bad are diagnosed because the
array elements overlap the subsequent members b and c. The third store is
diagnosed by -Warray-bounds because it is beyond the bounds of the
enclosing object.
struct X { int a[0]; int b, c; };
struct X x;
void bad (void)
{
x.a[0] = 0; // -Wzero-length-bounds
x.a[1] = 1; // -Wzero-length-bounds
x.a[2] = 2; // -Warray-bounds
}
Option -Wzero-length-bounds is enabled by -Warray-bounds.
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.huber at embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax: +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20220830/894a036b/attachment.htm>
More information about the devel
mailing list