On Mon, Aug 29, 2022 at 2:41 AM Sebastian Huber < 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 > >>> > >>> Author: Ryan Long<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. --joel > -- > embedded brains GmbH > Herr Sebastian HUBER > Dornierstr. 4 > 82178 Puchheim > Germany > email: sebastian.hu...@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/ >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel