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

[Sebastian Huber]

On 30/08/2022 00:24, Chris Johns wrote:
> 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.

The [0] was used sometimes in RTEMS for arrays with a flexible size. The 
[0] is a GNU extensions.

We introduced RTEMS_ZERO_LENGTH_ARRAY to work with flexible array 
members and not using this define for Scheduler_priority_Context was an 
oversight.

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

The scheduler context is statically initialized using:

   #define RTEMS_SCHEDULER_PRIORITY( name, prio_count ) \
     static struct { \
       Scheduler_priority_Context Base; \
       Chain_Control              Ready[ ( prio_count ) ]; \
     } SCHEDULER_PRIORITY_CONTEXT_NAME( name )

The number of supported priority levels depends on the application 
configuration.

This approach uses another GNU extension if flexible array members are 
used in "Base", since in this case the flexible array member is not the 
last member of struct SCHEDULER_PRIORITY_CONTEXT_NAME( name ).

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

Yes, basically everything which uses [0] in a structure definition or 
RTEMS_ZERO_LENGTH_ARRAY.

-- 
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/