[rtems commit] schedulerpriority.h: Fix gcc 12 warning

Joel Sherrill joel at rtems.org
Mon Aug 29 20:39:02 UTC 2022


On Mon, Aug 29, 2022 at 2:41 AM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> On 29/08/2022 09:30, Chris Johns wrote:
> > On 29/8/22 5:07 pm, Sebastian Huber wrote:
> >> On 19/08/2022 22:46, Joel Sherrill wrote:
> >>> Module:    rtems
> >>> Branch:    master
> >>> Commit:    5b875915152a248079855bcb98e871f70ac314cc
> >>> Changeset:
> >>>
> http://git.rtems.org/rtems/commit/?id=5b875915152a248079855bcb98e871f70ac314cc
> >>>
> >>> Author:    Ryan Long<ryan.long at oarcorp.com>
> >>> Date:      Tue Aug 16 12:00:26 2022 -0500
> >>>
> >>> schedulerpriority.h: Fix gcc 12 warning
> >>>
> >>> Changed the size of the array to 1 to get rid of the warning.
> >>>
> >>> Updates #4662
> >>>
> >>> ---
> >>>
> >>>    cpukit/include/rtems/score/schedulerpriority.h | 2 +-
> >>>    1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/cpukit/include/rtems/score/schedulerpriority.h
> >>> b/cpukit/include/rtems/score/schedulerpriority.h
> >>> index cf5d0762a9..e485e97c60 100644
> >>> --- a/cpukit/include/rtems/score/schedulerpriority.h
> >>> +++ b/cpukit/include/rtems/score/schedulerpriority.h
> >>> @@ -94,7 +94,7 @@ typedef struct {
> >>>      /**
> >>>       * @brief One ready queue per priority level.
> >>>       */
> >>> -  Chain_Control Ready[ 0 ];
> >>> +  Chain_Control Ready[ 1 ];
> >>>    } Scheduler_priority_Context;
> >> Increasing the storage size to fix a warning is the wrong approach.
> The warning
> >> should be suppressed in the application configuration header or the
> >> configuration should be changed to account for the new chain control.
> > Why do you say this is right or a better approach?
>
> A warning fix should not increase the storage size on the target. The
> Ready member is a flexible array those size is defined by the
> application configuration. This approach is used in several places. The
> declaration should be actually:
>
> Chain_Control Ready[ RTEMS_ZERO_LENGTH_ARRAY ];
>

The change to [1] was from a gcc documentation recommendation. Per
6.18 Arrays of Length Zero in the info installed with our GCC version, [0]
is a GNU extension and [1] is the C90 way to do it. We should not be using
a GNU extension.

In code which uses this construct (whether 0 or 1), if done in headers,
we can't assume users will compile with the array-bounds and/or
-Wzero-length-bounds disabled. If the warning is triggered in a header,
then it should be bracketed with the macros to disable the warning
temporarily.

--joel


> --
> 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/20220829/9b564517/attachment-0001.htm>


More information about the devel mailing list