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 ];
--
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
