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