On 30/8/2022 6:39 am, Joel Sherrill wrote: > On Mon, Aug 29, 2022 at 2:41 AM Sebastian Huber > <sebastian.hu...@embedded-brains.de > <mailto:sebastian.hu...@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.l...@oarcorp.com > <mailto:ryan.l...@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
