Hi, Sebastian,
Thanks for your explanation.
Our goal is to deprecate the GCC extension on structure containing a flexible
array member not at the end of another structure. In order to achieve this
goal, we provided the warning option -Wflex-array-member-not-at-end for the
users to
locate all such cases in their source code and update the source code to
eliminate such cases.
The static initialization of structures with flexible array members will still
work as long as the flexible array members are at
the end of the structures.
My question: is it possible to update your source code to move the structure
with flexible array member to the end of the
containing structure?
i.e, in your example, in the struct Thread_Configured_control, move the field
“Thread_Control Control” to the end of the structure?
Thanks
Qing
> On May 7, 2024, at 09:15, Sebastian Huber
> <sebastian.hu...@embedded-brains.de> wrote:
>
> On 06.05.24 16:20, Qing Zhao wrote:
>> Hi, Sebastian,
>> Looks like that the behavior you described is correct.
>> What’s your major concern? ( a little confused).
>
> I am concerned that the static initialization of structures with flexible
> array members no longer works. In the RTEMS open source real-time operating
> system, we use flexible array members in some parts. One example is the
> thread control block which is used to manage a thread:
>
> struct _Thread_Control {
> /** This field is the object management structure for each thread. */
> Objects_Control Object;
>
> [...]
>
> /**
> * @brief Variable length array of user extension pointers.
> *
> * The length is defined by the application via <rtems/confdefs.h>.
> */
> void *extensions[];
> };
>
> In a static configuration of the operating system we have something like this:
>
> struct Thread_Configured_control {
> /*
> * This was added to address the following warning.
> * warning: invalid use of structure with flexible array member
> */
> #pragma GCC diagnostic push
> #pragma GCC diagnostic ignored "-Wpedantic"
> Thread_Control Control;
> #pragma GCC diagnostic pop
>
> #if CONFIGURE_MAXIMUM_USER_EXTENSIONS > 0
> void *extensions[ CONFIGURE_MAXIMUM_USER_EXTENSIONS + 1 ];
> #endif
> Configuration_Scheduler_node Scheduler_nodes[ _CONFIGURE_SCHEDULER_COUNT ];
> RTEMS_API_Control API_RTEMS;
> #ifdef RTEMS_POSIX_API
> POSIX_API_Control API_POSIX;
> #endif
> #if CONFIGURE_MAXIMUM_THREAD_NAME_SIZE > 1
> char name[ CONFIGURE_MAXIMUM_THREAD_NAME_SIZE ];
> #endif
> #if defined(_CONFIGURE_ENABLE_NEWLIB_REENTRANCY) && \
> !defined(_REENT_THREAD_LOCAL)
> struct _reent Newlib;
> #endif
> };
>
> This is used to define a table of thread control blocks:
>
> Thread_Configured_control \
> name##_Objects[ _Objects_Maximum_per_allocation( max ) ]; \
> static RTEMS_SECTION( ".noinit.rtems.content.objects." #name ) \
>
> I would like no know which consequences the deprecation this GCC extension
> has.
>
> --
> embedded brains GmbH & Co. KG
> 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/
