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

[Chris Johns]

On 30/8/2022 6:39 am, Joel Sherrill wrote:
> On Mon, Aug 29, 2022 at 2:41 AM Sebastian Huber
> <sebastian.huber at embedded-brains.de <mailto: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
>     <http://git.rtems.org/rtems/commit/?id=5b875915152a248079855bcb98e871f70ac314cc>
>     >>>
>     >>> Author:    Ryan Long<ryan.long at oarcorp.com <mailto: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.

I can see why the compiler does not like `[0]`. Why waste time and effort
managing a variable that has no size? It looks like a coding convenience the
compiler is now warning about. I see no point fighting the compiler.

Sebastian, where does making it 1 effect the code or target data size?

Do we have more cases of this that need to be considered?

Chris