Re: [V2][PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.
> On May 7, 2024, at 17:52, Kees Cook wrote:
>
> On Tue, May 07, 2024 at 06:34:19PM +, Qing Zhao wrote:
>> On May 7, 2024, at 13:57, Sebastian Huber
>> wrote:
>>> On 07.05.24 16:26, Qing Zhao wrote:
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.
>>>
>>> What is the benefit of deprecating this GCC extension? If GCC
>>> extensions are removed, then it would be nice to enable the associated
>>> warnings by default.
>
> The goal of all of the recent array bounds and flexible array work is to
> make sizing information unambiguous (e.g. via __builtin_object_size(),
> __builtin_dynamic_object_size(), and the array-bounds sanitizer). For
> the compiler to be able to deterministically report size information
> on arrays, we needed to deprecate this case even though it had been
> supported in the past. (Though we also _added_ extensions to support
> for other things, like flexible arrays in unions, and the coming
> __counted_by attribute.)
>
> For example:
>
> struct flex { int length; char data[]; };
> struct mid_flex { int m; struct flex flex_data; int n; int o; };
>
> #define SZ(p) __builtin_dynamic_object_size(p, 1)
>
> void foo(struct flex *f, struct mid_flex *m)
> {
> printf("%zu\n", SZ(f));
> printf("%zu\n", SZ(m->flex_data));
> }
>
> int main(void)
> {
>struct mid_flex m = { .flex_data.length = 8 };
> foo(>flex_data, );
> return 0;
> }
>
> This is printing the size of the same object. But the desired results
> are ambiguous. Does m->flex_data have an unknown size (i.e. SIZE_MAX)
> because it's a flex array, or does it contain 8 bytes, since it overlaps
> with the other structure's trailing 2 ints?
>
> The answer from GCC 13 was neither:
>
> 18446744073709551615
> 4
>
> It considered flex_data to be only the size of it's non-flex-array
> members, but only when there was semantic context that it was part of
> another structure. (Yet more ambiguity.)
>
> In GCC 14, this is "resolved" to be unknown since it is a flex array
> which has no sizing info, and context doesn't matter:
>
> 18446744073709551615
> 18446744073709551615
>
> But this paves the way for the coming 'counted_by' attribute which will
> allow for struct flex above to be defined as:
>
> struct flex { int length; char data[] __attribute__((counted_by(length))); };
>
> At which point GCC can deterministically report the object size.
>
> Hopefully I've captured this all correctly -- Qing can correct me. :)
>
>>>
We had a long discussion before deciding to deprecating this GCC
extension. Please see details here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832
Yes, we do plan to enable this warning by default before final
deprecation. (Might consider to enable this warning by default in
GCC15… and then deprecate it in the next release)
Right now, there is an ongoing work in Linux kernel to get rid of
all such cases. Kees might have more information on this.
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.
>>>
>>> Removing the support for flexible array members in the middle of
>>> compounds will make the static initialization practically infeasible.
>>
>> If the flexible array member is moved to the end of the compounds,
>> the static initialization still work. What’s the issue here?
>>
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?
>>>
>>> If we move the Thread_Control to the end, how would I add a
>>> configuration defined number of elements at the end?
>>
>> Don’t understand this, why moving the Thread_Control Control” to
>> the end of the containing structure will make this a problem?
>> Could you please explain this with a simplified example?
>
> I found your example at [2] and tried to trim/summarize it here:
>
>
> struct _Thread_Control {
>Objects_Control Object;
>...
>void*extensions[];
> };
> typedef struct _Thread_Control Thread_Control;
>
> struct Thread_Configured_control {
> Thread_Control Control;
>
> #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
>
Re: [V2][PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.
On Tue, 7 May 2024, Kees Cook wrote:
> On Tue, May 07, 2024 at 06:34:19PM +, Qing Zhao wrote:
> > On May 7, 2024, at 13:57, Sebastian Huber
> > wrote:
> > > On 07.05.24 16:26, Qing Zhao wrote:
> > > > 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.
> > >
> > > What is the benefit of deprecating this GCC extension? If GCC
> > > extensions are removed, then it would be nice to enable the associated
> > > warnings by default.
>
> The goal of all of the recent array bounds and flexible array work is to
> make sizing information unambiguous (e.g. via __builtin_object_size(),
> __builtin_dynamic_object_size(), and the array-bounds sanitizer). For
> the compiler to be able to deterministically report size information
> on arrays, we needed to deprecate this case even though it had been
> supported in the past. (Though we also _added_ extensions to support
> for other things, like flexible arrays in unions, and the coming
> __counted_by attribute.)
>
> For example:
>
> struct flex { int length; char data[]; };
> struct mid_flex { int m; struct flex flex_data; int n; int o; };
It might be reasonable to allow tag-less "anonymous" struct that's
"completed" by means of the static initializer of a declared object, thus
struct { int m; struct { int length, char data[]; } flex_data; int n; int
o; } object
= { 3, { 2, { 1, 2 } }, 4, 5 };
The frontend would make the size of data[] static, determined by the
initializer. I _think_ the C standard makes object.flex_data
inter-operate with struct flex from above but struct mid_flex would
be an invalid type declaration and thus there's no way to have
an API with a pointer to such structure(?) which makes the extension
somewhat less useful.
>
> #define SZ(p) __builtin_dynamic_object_size(p, 1)
>
> void foo(struct flex *f, struct mid_flex *m)
> {
> printf("%zu\n", SZ(f));
> printf("%zu\n", SZ(m->flex_data));
> }
>
> int main(void)
> {
> struct mid_flex m = { .flex_data.length = 8 };
> foo(>flex_data, );
> return 0;
> }
>
> This is printing the size of the same object. But the desired results
> are ambiguous. Does m->flex_data have an unknown size (i.e. SIZE_MAX)
> because it's a flex array, or does it contain 8 bytes, since it overlaps
> with the other structure's trailing 2 ints?
>
> The answer from GCC 13 was neither:
>
> 18446744073709551615
> 4
>
> It considered flex_data to be only the size of it's non-flex-array
> members, but only when there was semantic context that it was part of
> another structure. (Yet more ambiguity.)
>
> In GCC 14, this is "resolved" to be unknown since it is a flex array
> which has no sizing info, and context doesn't matter:
>
> 18446744073709551615
> 18446744073709551615
>
> But this paves the way for the coming 'counted_by' attribute which will
> allow for struct flex above to be defined as:
>
> struct flex { int length; char data[] __attribute__((counted_by(length))); };
>
> At which point GCC can deterministically report the object size.
>
> Hopefully I've captured this all correctly -- Qing can correct me. :)
>
> > >
> > > > We had a long discussion before deciding to deprecating this GCC
> > > > extension. Please see details here:
> > > >
> > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832
> > > >
> > > > Yes, we do plan to enable this warning by default before final
> > > > deprecation. (Might consider to enable this warning by default in
> > > > GCC15… and then deprecate it in the next release)
> > > >
> > > > Right now, there is an ongoing work in Linux kernel to get rid of
> > > > all such cases. Kees might have more information on this.
> > > >
> > > >
> > > > 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.
> > >
> > > Removing the support for flexible array members in the middle of
> > > compounds will make the static initialization practically infeasible.
> >
> > If the flexible array member is moved to the end of the compounds,
> > the static initialization still work. What’s the issue here?
> >
> > > > 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?
> > >
> > > If we move the Thread_Control to the end, how would I add a
> > > configuration defined number of elements at the end?
> >
> > Don’t
Re: [V2][PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.
On Tue, May 07, 2024 at 06:34:19PM +, Qing Zhao wrote:
> On May 7, 2024, at 13:57, Sebastian Huber
> wrote:
> > On 07.05.24 16:26, Qing Zhao wrote:
> > > 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.
> >
> > What is the benefit of deprecating this GCC extension? If GCC
> > extensions are removed, then it would be nice to enable the associated
> > warnings by default.
The goal of all of the recent array bounds and flexible array work is to
make sizing information unambiguous (e.g. via __builtin_object_size(),
__builtin_dynamic_object_size(), and the array-bounds sanitizer). For
the compiler to be able to deterministically report size information
on arrays, we needed to deprecate this case even though it had been
supported in the past. (Though we also _added_ extensions to support
for other things, like flexible arrays in unions, and the coming
__counted_by attribute.)
For example:
struct flex { int length; char data[]; };
struct mid_flex { int m; struct flex flex_data; int n; int o; };
#define SZ(p) __builtin_dynamic_object_size(p, 1)
void foo(struct flex *f, struct mid_flex *m)
{
printf("%zu\n", SZ(f));
printf("%zu\n", SZ(m->flex_data));
}
int main(void)
{
struct mid_flex m = { .flex_data.length = 8 };
foo(>flex_data, );
return 0;
}
This is printing the size of the same object. But the desired results
are ambiguous. Does m->flex_data have an unknown size (i.e. SIZE_MAX)
because it's a flex array, or does it contain 8 bytes, since it overlaps
with the other structure's trailing 2 ints?
The answer from GCC 13 was neither:
18446744073709551615
4
It considered flex_data to be only the size of it's non-flex-array
members, but only when there was semantic context that it was part of
another structure. (Yet more ambiguity.)
In GCC 14, this is "resolved" to be unknown since it is a flex array
which has no sizing info, and context doesn't matter:
18446744073709551615
18446744073709551615
But this paves the way for the coming 'counted_by' attribute which will
allow for struct flex above to be defined as:
struct flex { int length; char data[] __attribute__((counted_by(length))); };
At which point GCC can deterministically report the object size.
Hopefully I've captured this all correctly -- Qing can correct me. :)
> >
> > > We had a long discussion before deciding to deprecating this GCC
> > > extension. Please see details here:
> > >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832
> > >
> > > Yes, we do plan to enable this warning by default before final
> > > deprecation. (Might consider to enable this warning by default in
> > > GCC15… and then deprecate it in the next release)
> > >
> > > Right now, there is an ongoing work in Linux kernel to get rid of
> > > all such cases. Kees might have more information on this.
> > >
> > >
> > > 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.
> >
> > Removing the support for flexible array members in the middle of
> > compounds will make the static initialization practically infeasible.
>
> If the flexible array member is moved to the end of the compounds,
> the static initialization still work. What’s the issue here?
>
> > > 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?
> >
> > If we move the Thread_Control to the end, how would I add a
> > configuration defined number of elements at the end?
>
> Don’t understand this, why moving the Thread_Control Control” to
> the end of the containing structure will make this a problem?
> Could you please explain this with a simplified example?
I found your example at [2] and tried to trim/summarize it here:
struct _Thread_Control {
Objects_Control Object;
...
void*extensions[];
};
typedef struct _Thread_Control Thread_Control;
struct Thread_Configured_control {
Thread_Control Control;
#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
Re: [V2][PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.
(Resend since my previous email in HTML and inline quoting wasn’t work, I changed the mail setting, hopefully this time it’s good). Sorry for the inconvenience. > On May 7, 2024, at 13:57, Sebastian Huber > wrote: > > On 07.05.24 16:26, Qing Zhao wrote: >> 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. > > What is the benefit of deprecating this GCC extension? If GCC extensions are > removed, then it would be nice to enable the associated warnings by default. We had a long discussion before deciding to deprecating this GCC extension. Please see details here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832 Yes, we do plan to enable this warning by default before final deprecation. (Might consider to enable this warning by default in GCC15… and then deprecate it in the next release) Right now, there is an ongoing work in Linux kernel to get rid of all such cases. Kees might have more information on this. > >> 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. > > Removing the support for flexible array members in the middle of compounds > will make the static initialization practically infeasible. If the flexible array member is moved to the end of the compounds, the static initialization still work. What’s the issue here? > >> 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? > > If we move the Thread_Control to the end, how would I add a configuration > defined number of elements at the end? Don’t understand this, why moving the Thread_Control Control” to the end of the containing structure will make this a problem? Could you please explain this with a simplified example? Thanks. Qing > > -- > 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/
Re: [V2][PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.
On May 7, 2024, at 13:57, Sebastian Huber wrote: On 07.05.24 16:26, Qing Zhao wrote: 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. What is the benefit of deprecating this GCC extension? If GCC extensions are removed, then it would be nice to enable the associated warnings by default. We had a long discussion before deciding to deprecating this GCC extension. Please see details here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832 Yes, we do plan to enable this warning by default before final deprecation. (Might consider to enable this warning by default in GCC15… and then deprecate it in the next release) Right now, there is an ongoing work in Linux kernel to get rid of all such cases. Kees might have more information on this. 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. Removing the support for flexible array members in the middle of compounds will make the static initialization practically infeasible. If the flexible array member is moved to the end of the compounds, the static initialization still work. What’s the issue here? 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? If we move the Thread_Control to the end, how would I add a configuration defined number of elements at the end? Don’t understand this, why moving the Thread_Control Control” to the end of the containing structure will make this a problem? Could you please explain this with a simplified example? Thanks. Qing -- 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/
Re: [V2][PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.
On 07.05.24 16:26, Qing Zhao wrote: 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. What is the benefit of deprecating this GCC extension? If GCC extensions are removed, then it would be nice to enable the associated warnings by default. 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. Removing the support for flexible array members in the middle of compounds will make the static initialization practically infeasible. 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? If we move the Thread_Control to the end, how would I add a configuration defined number of elements at the end? -- 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/
Re: [V2][PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.
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
> 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 .
> */
> 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/
Re: [V2][PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.
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 .
*/
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/
Re: [V2][PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.
Hi, Sebastian,
Looks like that the behavior you described is correct.
What’s your major concern? ( a little confused).
Qing
On May 6, 2024, at 09:29, Sebastian Huber
wrote:
On 06.05.24 09:08, Richard Biener wrote:
On Sat, 4 May 2024, Sebastian Huber wrote:
On 07.08.23 16:22, Qing Zhao via Gcc-patches wrote:
Hi,
This is the 2nd version of the patch.
Comparing to the 1st version, the only change is to address Richard's
comment on refering a warning option for diagnosing deprecated behavior.
Okay for committing?
thanks.
Qing
==
*htdocs/gcc-14/changes.html (Caveats): Add notice about deprecating a C
extension about flexible array members.
---
htdocs/gcc-14/changes.html | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index dad1ba53..eae25f1a 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -30,7 +30,18 @@ a work-in-progress.
Caveats
- ...
+ C:
+ Support for the GCC extension, a structure containing a C99 flexible
array
+ member, or a union containing such a structure, is not the last field
of
+ another structure, is deprecated. Refer to
+ https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html;>
+ Zero Length Arrays.
+ Any code relying on this extension should be modifed to ensure that
+ C99 flexible array members only end up at the ends of structures.
+ Please use the warning option
+ https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wflex-array-member-not-at-end;>-Wflex-array-member-not-at-end
to
+ identify all such cases in the source code and modify them.
+
I have a question with respect to the static initialization of flexible array
members. According to the documentation this is supported by GCC:
https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
"GCC allows static initialization of flexible array members. This is
equivalent to defining a new structure containing the original structure
followed by an array of sufficient size to contain the data. E.g. in the
following, f1 is constructed as if it were declared like f2.
struct f1 {
int x; int y[];
} f1 = { 1, { 2, 3, 4 } };
struct f2 {
struct f1 f1; int data[3];
} f2 = { { 1 }, { 2, 3, 4 } };
"
However, when I compile this code, I get a warning like this:
flex-array.c:6:13: warning: structure containing a flexible array member is
not at the end of another structure [-Wflex-array-member-not-at-end]
6 | struct f1 f1; int data[3];
|
In general, I agree that flexible array members should be at the end, however
the support for static initialization is quite important from my point of view
especially for applications for embedded systems. Here, dynamic allocations
may not be allowed or feasible.
I do not get a diagnostic for this on trunk? And I agree there shouldn't
be any.
It seems that this warning is not enabled by -Wall and -Wextra. I tried this:
gcc -Wflex-array-member-not-at-end -S -o - flex-array.c
.file "flex-array.c"
flex-array.c:6:13: warning: structure containing a flexible array member is not
at the end of another structure [-Wflex-array-member-not-at-end]
6 | struct f1 f1; int data[3];
| ^~
.text
.globl f1
.data
.align 4
.type f1, @object
.size f1, 16
f1:
.long 1
.long 2
.long 3
.long 4
.globl f2
.align 16
.type f2, @object
.size f2, 16
f2:
.long 1
.long 2
.long 3
.long 4
.ident "GCC: (GNU) 15.0.0 20240506 (experimental) [master ec1cdad89af]"
.section.note.GNU-stack,"",@progbits
--
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/
Re: [V2][PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.
On 06.05.24 09:08, Richard Biener wrote:
On Sat, 4 May 2024, Sebastian Huber wrote:
On 07.08.23 16:22, Qing Zhao via Gcc-patches wrote:
Hi,
This is the 2nd version of the patch.
Comparing to the 1st version, the only change is to address Richard's
comment on refering a warning option for diagnosing deprecated behavior.
Okay for committing?
thanks.
Qing
==
*htdocs/gcc-14/changes.html (Caveats): Add notice about deprecating a C
extension about flexible array members.
---
htdocs/gcc-14/changes.html | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index dad1ba53..eae25f1a 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -30,7 +30,18 @@ a work-in-progress.
Caveats
- ...
+ C:
+ Support for the GCC extension, a structure containing a C99 flexible
array
+ member, or a union containing such a structure, is not the last field
of
+ another structure, is deprecated. Refer to
+ https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html;>
+ Zero Length Arrays.
+ Any code relying on this extension should be modifed to ensure that
+ C99 flexible array members only end up at the ends of structures.
+ Please use the warning option
+ https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wflex-array-member-not-at-end;>-Wflex-array-member-not-at-end
to
+ identify all such cases in the source code and modify them.
+
I have a question with respect to the static initialization of flexible array
members. According to the documentation this is supported by GCC:
https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
"GCC allows static initialization of flexible array members. This is
equivalent to defining a new structure containing the original structure
followed by an array of sufficient size to contain the data. E.g. in the
following, f1 is constructed as if it were declared like f2.
struct f1 {
int x; int y[];
} f1 = { 1, { 2, 3, 4 } };
struct f2 {
struct f1 f1; int data[3];
} f2 = { { 1 }, { 2, 3, 4 } };
"
However, when I compile this code, I get a warning like this:
flex-array.c:6:13: warning: structure containing a flexible array member is
not at the end of another structure [-Wflex-array-member-not-at-end]
6 | struct f1 f1; int data[3];
|
In general, I agree that flexible array members should be at the end, however
the support for static initialization is quite important from my point of view
especially for applications for embedded systems. Here, dynamic allocations
may not be allowed or feasible.
I do not get a diagnostic for this on trunk? And I agree there shouldn't
be any.
It seems that this warning is not enabled by -Wall and -Wextra. I tried
this:
gcc -Wflex-array-member-not-at-end -S -o - flex-array.c
.file "flex-array.c"
flex-array.c:6:13: warning: structure containing a flexible array member
is not at the end of another structure [-Wflex-array-member-not-at-end]
6 | struct f1 f1; int data[3];
| ^~
.text
.globl f1
.data
.align 4
.type f1, @object
.size f1, 16
f1:
.long 1
.long 2
.long 3
.long 4
.globl f2
.align 16
.type f2, @object
.size f2, 16
f2:
.long 1
.long 2
.long 3
.long 4
.ident "GCC: (GNU) 15.0.0 20240506 (experimental) [master
ec1cdad89af]"
.section.note.GNU-stack,"",@progbits
--
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/
Re: [V2][PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.
On Sat, 4 May 2024, Sebastian Huber wrote:
> On 07.08.23 16:22, Qing Zhao via Gcc-patches wrote:
> > Hi,
> >
> > This is the 2nd version of the patch.
> > Comparing to the 1st version, the only change is to address Richard's
> > comment on refering a warning option for diagnosing deprecated behavior.
> >
> >
> > Okay for committing?
> >
> > thanks.
> >
> > Qing
> >
> > ==
> >
> > *htdocs/gcc-14/changes.html (Caveats): Add notice about deprecating a C
> > extension about flexible array members.
> > ---
> > htdocs/gcc-14/changes.html | 13 -
> > 1 file changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
> > index dad1ba53..eae25f1a 100644
> > --- a/htdocs/gcc-14/changes.html
> > +++ b/htdocs/gcc-14/changes.html
> > @@ -30,7 +30,18 @@ a work-in-progress.
> >
> > Caveats
> >
> > - ...
> > + C:
> > + Support for the GCC extension, a structure containing a C99 flexible
> > array
> > + member, or a union containing such a structure, is not the last field
> > of
> > + another structure, is deprecated. Refer to
> > + https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html;>
> > + Zero Length Arrays.
> > + Any code relying on this extension should be modifed to ensure that
> > + C99 flexible array members only end up at the ends of structures.
> > + Please use the warning option
> > + > href="https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wflex-array-member-not-at-end;>-Wflex-array-member-not-at-end
> > to
> > + identify all such cases in the source code and modify them.
> > +
> >
>
> I have a question with respect to the static initialization of flexible array
> members. According to the documentation this is supported by GCC:
>
> https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
>
> "GCC allows static initialization of flexible array members. This is
> equivalent to defining a new structure containing the original structure
> followed by an array of sufficient size to contain the data. E.g. in the
> following, f1 is constructed as if it were declared like f2.
>
> struct f1 {
> int x; int y[];
> } f1 = { 1, { 2, 3, 4 } };
>
> struct f2 {
> struct f1 f1; int data[3];
> } f2 = { { 1 }, { 2, 3, 4 } };
> "
>
> However, when I compile this code, I get a warning like this:
>
> flex-array.c:6:13: warning: structure containing a flexible array member is
> not at the end of another structure [-Wflex-array-member-not-at-end]
> 6 | struct f1 f1; int data[3];
> |
>
> In general, I agree that flexible array members should be at the end, however
> the support for static initialization is quite important from my point of view
> especially for applications for embedded systems. Here, dynamic allocations
> may not be allowed or feasible.
I do not get a diagnostic for this on trunk? And I agree there shouldn't
be any.
Richard.
Re: [V2][PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.
On 07.08.23 16:22, Qing Zhao via Gcc-patches wrote:
Hi,
This is the 2nd version of the patch.
Comparing to the 1st version, the only change is to address Richard's
comment on refering a warning option for diagnosing deprecated behavior.
Okay for committing?
thanks.
Qing
==
*htdocs/gcc-14/changes.html (Caveats): Add notice about deprecating a C
extension about flexible array members.
---
htdocs/gcc-14/changes.html | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index dad1ba53..eae25f1a 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -30,7 +30,18 @@ a work-in-progress.
Caveats
- ...
+ C:
+ Support for the GCC extension, a structure containing a C99 flexible
array
+ member, or a union containing such a structure, is not the last field of
+ another structure, is deprecated. Refer to
+ https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html;>
+ Zero Length Arrays.
+ Any code relying on this extension should be modifed to ensure that
+ C99 flexible array members only end up at the ends of structures.
+ Please use the warning option
+ https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wflex-array-member-not-at-end;>-Wflex-array-member-not-at-end
to
+ identify all such cases in the source code and modify them.
+
I have a question with respect to the static initialization of flexible
array members. According to the documentation this is supported by GCC:
https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
"GCC allows static initialization of flexible array members. This is
equivalent to defining a new structure containing the original structure
followed by an array of sufficient size to contain the data. E.g. in the
following, f1 is constructed as if it were declared like f2.
struct f1 {
int x; int y[];
} f1 = { 1, { 2, 3, 4 } };
struct f2 {
struct f1 f1; int data[3];
} f2 = { { 1 }, { 2, 3, 4 } };
"
However, when I compile this code, I get a warning like this:
flex-array.c:6:13: warning: structure containing a flexible array member
is not at the end of another structure [-Wflex-array-member-not-at-end]
6 | struct f1 f1; int data[3];
|
In general, I agree that flexible array members should be at the end,
however the support for static initialization is quite important from my
point of view especially for applications for embedded systems. Here,
dynamic allocations may not be allowed or feasible.
--
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/
Re: Improve -Wflex-array-member-not-at-end changes.html wording |Plus: and warning bug? (was: [V2][PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.)
On Thu, Oct 19, 2023 at 08:49:00PM +, Qing Zhao wrote: > > On Sep 25, 2023, at 2:24 PM, Tobias Burnus wrote: > > Secondly, if this is deprecated, shouldn't then the warning enabled by, > > e.g., -Wall or made > > otherwise more prominent? (-std=?) - Currently, one either has to find the > > new flag or use > > -pedantic. > > Yes, agreed, However, I think that it might be better to delay this to next > GCC release by giving users plenty time to fix all the > -Wflex-array-member-not-at-end warnings. As I know, linux kernel exposed a > lot of warnings when adding -Wflex-array-member-not-at-end, and kernel people > are trying to fix all these warnings in the source base. Yeah, for the code bases that use flexible arrays (C99 or GNU Extension), there are cases where they're used as intentional implicit unions, and the refactoring to make them unambiguous is non-trivial. I think it may need to be some time before -Wflex-array-member-not-at-end ends up in -Wall. I gave some examples of this code pattern (and potential solutions) here: https://lore.kernel.org/lkml/202310161249.43FB42A6@keescook -- Kees Cook
Re: Improve -Wflex-array-member-not-at-end changes.html wording |Plus: and warning bug? (was: [V2][PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.)
Hi, Tobias,
Sorry for the late reply (just came back from a long vacation after Cauldron).
And thank you for reporting this issue.
Please see my reply embedded below:
> On Sep 25, 2023, at 2:24 PM, Tobias Burnus wrote:
>
> Hi all,
>
> I stumbled over this as I found the wording in the release notes rather
> unclear.is.
>
>
> First, the following gives only a -pedantic warning and not a
> -Wflex-array-member-not-at-end:
>
> struct t { int b; int x[]; };
> struct q { int b; struct t a[2]; int c; };
>
> warning: invalid use of structure with flexible array member [-Wpedantic]
>
> If I remove the "[2]", it shows additionally:
> warning: structure containing a flexible array member is not at the end of
> another structure [-Wflex-array-member-not-at-end]
I think that the above behavior is correct as Richard mentioned previously. -:)
First, by C99, a structure with flexible array member cannot be an element of
an array,
Therefore, struct t a[2] is an incorrect usage, the warning:
warning: invalid use of structure with flexible array member [-Wpedantic]
is complaining about this standard violation. Though the diagnositic message
might need to be more specific like the following:
Warning: invalid use of structure with flexible array member as array element
[-Wpedantic]
Then, after fixing this standard violation issue, the testing case is as
following:
struct t { int b; int x[]; };
struct q { int b; struct t a; int c; };
adding -Wflex-array-member-not-at-end will report the expecting message:
/home/opc/Install/latest/bin/gcc -O -Wflex-array-member-not-at-end t.c -S
t.c:2:29: warning: structure containing a flexible array member is not at the
end of another structure [-Wflex-array-member-not-at-end]
2 | struct q { int b; struct t a; int c; };
| ^
So, I think that GCC’s behavior is correct.
However, we might need to make the diagnostic message more accurate here (I can
submit a small patch to improve this).
>
> It seems as if it should print latter warning also inside the struct.
>
> Qing? Joseph? Thoughts?
>
> * * *
>
> Secondly, if this is deprecated, shouldn't then the warning enabled by, e.g.,
> -Wall or made
> otherwise more prominent? (-std=?) - Currently, one either has to find the
> new flag or use
> -pedantic.
Yes, agreed, However, I think that it might be better to delay this to next GCC
release by giving users plenty time to fix all the
-Wflex-array-member-not-at-end warnings. As I know, linux kernel exposed a lot
of warnings when adding -Wflex-array-member-not-at-end, and kernel people are
trying to fix all these warnings in the source base.
>
> Or is this not really regarded as deprecated? But then (IMHO) we should not
> really claim so and just
> add the warning without deprecation.
I think that our final goal is to deprecate this ambiguous extension from GCC
completely, but we need time to mitigate users step by step.
>
> BTW; clang-15 prints the -Wgnu-variable-sized-type-not-at-end warning by
> default.
>
> Joseph, all: Thoughts?
>
> * * *
>
> Cross ref: The patch adding the new warning is r14-2197-g070a6bf0bdc6761
> https://gcc.gnu.org/pipermail/gcc-cvs/2023-June/385730.html (cf. previously
> in this thread)
>
>
> * * *
>
> Regarding the changes.html wording:
>
> On 07.08.23 16:22, Qing Zhao via Gcc-patches wrote:
>
>> Comparing to the 1st version, the only change is to address Richard's
>> comment on refering a warning option for diagnosing deprecated behavior.
> ...
>> +++ b/htdocs/gcc-14/changes.html
>> @@ -30,7 +30,18 @@ a work-in-progress.
>>
>> Caveats
>>
>> - ...
>> + C:
>> + Support for the GCC extension, a structure containing a C99 flexible
>> array
>> + member, or a union containing such a structure, is not the last field
>> of
>> + another structure, is deprecated. Refer to
>> + https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html;>
>> + Zero Length Arrays.
>
> ...
>
> I find the first sentence difficult to read. What do you think of the
> following?
> (It is hard to come up with some good wording.)
>
> --- a/htdocs/gcc-14/changes.html
> +++ b/htdocs/gcc-14/changes.html
> @@ -31,9 +31,10 @@ a work-in-progress.
> Caveats
>
> C:
> - Support for the GCC extension, a structure containing a C99 flexible
> array
> - member, or a union containing such a structure, is not the last field
> of
> - another structure, is deprecated. Refer to
> + Support for the GCC extension that a structure containing a C99
> flexible
> + array (and any union containing a member of such structure) can be a
> + member of a structure has been deprecated for the case that it is not
> + the last member. Refer to
> https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html;>
> Zero Length Arrays.
> Any code relying on this extension should be modifed to ensure that
I felt the above is more difficult to understand… how
Re: Improve -Wflex-array-member-not-at-end changes.html wording |Plus: and warning bug? (was: [V2][PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.)
Hi, Tobias,
Sorry for the late reply.
I has been on vacation after Cauldron, and will be back to work in the mid of
Oct. will look at this issue at that time.
Qing
> On Sep 25, 2023, at 2:24 PM, Tobias Burnus wrote:
>
> Hi all,
>
> I stumbled over this as I found the wording in the release notes rather
> unclear.is.
>
>
> First, the following gives only a -pedantic warning and not a
> -Wflex-array-member-not-at-end:
>
> struct t { int b; int x[]; };
> struct q { int b; struct t a[2]; int c; };
>
> warning: invalid use of structure with flexible array member [-Wpedantic]
>
> If I remove the "[2]", it shows additionally:
> warning: structure containing a flexible array member is not at the end of
> another structure [-Wflex-array-member-not-at-end]
>
> It seems as if it should print latter warning also inside the struct.
>
> Qing? Joseph? Thoughts?
>
> * * *
>
> Secondly, if this is deprecated, shouldn't then the warning enabled by, e.g.,
> -Wall or made
> otherwise more prominent? (-std=?) - Currently, one either has to find the
> new flag or use
> -pedantic.
>
> Or is this not really regarded as deprecated? But then (IMHO) we should not
> really claim so and just
> add the warning without deprecation.
>
> BTW; clang-15 prints the -Wgnu-variable-sized-type-not-at-end warning by
> default.
>
> Joseph, all: Thoughts?
>
> * * *
>
> Cross ref: The patch adding the new warning is r14-2197-g070a6bf0bdc6761
> https://gcc.gnu.org/pipermail/gcc-cvs/2023-June/385730.html (cf. previously
> in this thread)
>
>
> * * *
>
> Regarding the changes.html wording:
>
> On 07.08.23 16:22, Qing Zhao via Gcc-patches wrote:
>
>> Comparing to the 1st version, the only change is to address Richard's
>> comment on refering a warning option for diagnosing deprecated behavior.
> ...
>> +++ b/htdocs/gcc-14/changes.html
>> @@ -30,7 +30,18 @@ a work-in-progress.
>>
>> Caveats
>>
>> - ...
>> + C:
>> + Support for the GCC extension, a structure containing a C99 flexible
>> array
>> + member, or a union containing such a structure, is not the last field
>> of
>> + another structure, is deprecated. Refer to
>> + https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html;>
>> + Zero Length Arrays.
>
> ...
>
> I find the first sentence difficult to read. What do you think of the
> following?
> (It is hard to come up with some good wording.)
>
> --- a/htdocs/gcc-14/changes.html
> +++ b/htdocs/gcc-14/changes.html
> @@ -31,9 +31,10 @@ a work-in-progress.
> Caveats
>
> C:
> - Support for the GCC extension, a structure containing a C99 flexible
> array
> - member, or a union containing such a structure, is not the last field
> of
> - another structure, is deprecated. Refer to
> + Support for the GCC extension that a structure containing a C99
> flexible
> + array (and any union containing a member of such structure) can be a
> + member of a structure has been deprecated for the case that it is not
> + the last member. Refer to
> https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html;>
> Zero Length Arrays.
> Any code relying on this extension should be modifed to ensure that
>
>
> Tobias
>
> PS: C17 has:
> "A structure or union shall not contain a member with incomplete or function
> type (hence, a structure
> shall not contain an instance of itself, but may contain a pointer to an
> instance of itself), except that
> the last member of a structure with more than one named member may have
> incomplete array type;
> such a structure (and any union containing, possibly recursively, a member
> that is such a structure)
> shall not be a member of a structure or an element of an array."
>
> -
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
> München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
> Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
> München, HRB 106955
Re: Improve -Wflex-array-member-not-at-end changes.html wording |Plus: and warning bug? (was: [V2][PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.)
On Mon, 25 Sep 2023, Tobias Burnus wrote:
> Hi all,
>
> I stumbled over this as I found the wording in the release notes rather
> unclear.is.
>
>
> First, the following gives only a -pedantic warning and not a
> -Wflex-array-member-not-at-end:
>
> struct t { int b; int x[]; };
> struct q { int b; struct t a[2]; int c; };
>
> warning: invalid use of structure with flexible array member [-Wpedantic]
>
> If I remove the "[2]", it shows additionally:
> warning: structure containing a flexible array member is not at the end of
> another structure [-Wflex-array-member-not-at-end]
>
> It seems as if it should print latter warning also inside the struct.
>
> Qing? Joseph? Thoughts?
I think an array element with a flex array is invalid and this is what
is diagnosed here. Maybe it should say ' as array element'
> * * *
>
> Secondly, if this is deprecated, shouldn't then the warning enabled by, e.g.,
> -Wall or made
> otherwise more prominent? (-std=?) - Currently, one either has to find the new
> flag or use
> -pedantic.
>
> Or is this not really regarded as deprecated? But then (IMHO) we should not
> really claim so and just
> add the warning without deprecation.
>
> BTW; clang-15 prints the -Wgnu-variable-sized-type-not-at-end warning by
> default.
>
> Joseph, all: Thoughts?
>
> * * *
>
> Cross ref: The patch adding the new warning is r14-2197-g070a6bf0bdc6761
> https://gcc.gnu.org/pipermail/gcc-cvs/2023-June/385730.html (cf. previously in
> this thread)
>
>
> * * *
>
> Regarding the changes.html wording:
>
> On 07.08.23 16:22, Qing Zhao via Gcc-patches wrote:
>
> > Comparing to the 1st version, the only change is to address Richard's
> > comment on refering a warning option for diagnosing deprecated behavior.
> ...
> > +++ b/htdocs/gcc-14/changes.html
> > @@ -30,7 +30,18 @@ a work-in-progress.
> >
> > Caveats
> >
> > - ...
> > + C:
> > + Support for the GCC extension, a structure containing a C99 flexible
> > array
> > + member, or a union containing such a structure, is not the last field
> > of
> > + another structure, is deprecated. Refer to
> > + https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html;>
> > + Zero Length Arrays.
>
> ...
>
> I find the first sentence difficult to read. What do you think of the
> following?
> (It is hard to come up with some good wording.)
>
> --- a/htdocs/gcc-14/changes.html
> +++ b/htdocs/gcc-14/changes.html
> @@ -31,9 +31,10 @@ a work-in-progress.
> Caveats
>
>C:
> - Support for the GCC extension, a structure containing a C99 flexible
> array
> - member, or a union containing such a structure, is not the last field
> of
> - another structure, is deprecated. Refer to
> + Support for the GCC extension that a structure containing a C99
> flexible
> + array (and any union containing a member of such structure) can be a
> + member of a structure has been deprecated for the case that it is not
> + the last member. Refer to
>https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html;>
>Zero Length Arrays.
>Any code relying on this extension should be modifed to ensure that
>
>
> Tobias
>
> PS: C17 has:
> "A structure or union shall not contain a member with incomplete or function
> type (hence, a structure
> shall not contain an instance of itself, but may contain a pointer to an
> instance of itself), except that
> the last member of a structure with more than one named member may have
> incomplete array type;
> such a structure (and any union containing, possibly recursively, a member
> that is such a structure)
> shall not be a member of a structure or an element of an array."
>
> -
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra?e 201, 80634
> M?nchen; Gesellschaft mit beschr?nkter Haftung; Gesch?ftsf?hrer: Thomas
> Heurung, Frank Th?rauf; Sitz der Gesellschaft: M?nchen; Registergericht
> M?nchen, HRB 106955
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
Improve -Wflex-array-member-not-at-end changes.html wording |Plus: and warning bug? (was: [V2][PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.)
Hi all,
I stumbled over this as I found the wording in the release notes rather
unclear.is.
First, the following gives only a -pedantic warning and not a
-Wflex-array-member-not-at-end:
struct t { int b; int x[]; };
struct q { int b; struct t a[2]; int c; };
warning: invalid use of structure with flexible array member [-Wpedantic]
If I remove the "[2]", it shows additionally:
warning: structure containing a flexible array member is not at the end of
another structure [-Wflex-array-member-not-at-end]
It seems as if it should print latter warning also inside the struct.
Qing? Joseph? Thoughts?
* * *
Secondly, if this is deprecated, shouldn't then the warning enabled by, e.g.,
-Wall or made
otherwise more prominent? (-std=?) - Currently, one either has to find the new
flag or use
-pedantic.
Or is this not really regarded as deprecated? But then (IMHO) we should not
really claim so and just
add the warning without deprecation.
BTW; clang-15 prints the -Wgnu-variable-sized-type-not-at-end warning by
default.
Joseph, all: Thoughts?
* * *
Cross ref: The patch adding the new warning is r14-2197-g070a6bf0bdc6761
https://gcc.gnu.org/pipermail/gcc-cvs/2023-June/385730.html (cf. previously in
this thread)
* * *
Regarding the changes.html wording:
On 07.08.23 16:22, Qing Zhao via Gcc-patches wrote:
Comparing to the 1st version, the only change is to address Richard's
comment on refering a warning option for diagnosing deprecated behavior.
...
+++ b/htdocs/gcc-14/changes.html
@@ -30,7 +30,18 @@ a work-in-progress.
Caveats
- ...
+ C:
+ Support for the GCC extension, a structure containing a C99 flexible
array
+ member, or a union containing such a structure, is not the last field of
+ another structure, is deprecated. Refer to
+ https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html;>
+ Zero Length Arrays.
...
I find the first sentence difficult to read. What do you think of the following?
(It is hard to come up with some good wording.)
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -31,9 +31,10 @@ a work-in-progress.
Caveats
C:
- Support for the GCC extension, a structure containing a C99 flexible
array
- member, or a union containing such a structure, is not the last field of
- another structure, is deprecated. Refer to
+ Support for the GCC extension that a structure containing a C99 flexible
+ array (and any union containing a member of such structure) can be a
+ member of a structure has been deprecated for the case that it is not
+ the last member. Refer to
https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html;>
Zero Length Arrays.
Any code relying on this extension should be modifed to ensure that
Tobias
PS: C17 has:
"A structure or union shall not contain a member with incomplete or function
type (hence, a structure
shall not contain an instance of itself, but may contain a pointer to an
instance of itself), except that
the last member of a structure with more than one named member may have
incomplete array type;
such a structure (and any union containing, possibly recursively, a member
that is such a structure)
shall not be a member of a structure or an element of an array."
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
Re: [V2][PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.
On Mon, 7 Aug 2023, Qing Zhao wrote: > Hi, > > This is the 2nd version of the patch. > Comparing to the 1st version, the only change is to address Richard's > comment on refering a warning option for diagnosing deprecated behavior. > > > Okay for committing? OK. > thanks. > > Qing > > == > > *htdocs/gcc-14/changes.html (Caveats): Add notice about deprecating a C > extension about flexible array members. > --- > htdocs/gcc-14/changes.html | 13 - > 1 file changed, 12 insertions(+), 1 deletion(-) > > diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html > index dad1ba53..eae25f1a 100644 > --- a/htdocs/gcc-14/changes.html > +++ b/htdocs/gcc-14/changes.html > @@ -30,7 +30,18 @@ a work-in-progress. > > Caveats > > - ... > + C: > + Support for the GCC extension, a structure containing a C99 flexible > array > + member, or a union containing such a structure, is not the last field > of > + another structure, is deprecated. Refer to > + https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html;> > + Zero Length Arrays. > + Any code relying on this extension should be modifed to ensure that > + C99 flexible array members only end up at the ends of structures. > + Please use the warning option > + href="https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wflex-array-member-not-at-end;>-Wflex-array-member-not-at-end > to > + identify all such cases in the source code and modify them. > + > > > > -- Richard Biener SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
[V2][PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.
Hi, This is the 2nd version of the patch. Comparing to the 1st version, the only change is to address Richard's comment on refering a warning option for diagnosing deprecated behavior. Okay for committing? thanks. Qing == *htdocs/gcc-14/changes.html (Caveats): Add notice about deprecating a C extension about flexible array members. --- htdocs/gcc-14/changes.html | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html index dad1ba53..eae25f1a 100644 --- a/htdocs/gcc-14/changes.html +++ b/htdocs/gcc-14/changes.html @@ -30,7 +30,18 @@ a work-in-progress. Caveats - ... + C: + Support for the GCC extension, a structure containing a C99 flexible array + member, or a union containing such a structure, is not the last field of + another structure, is deprecated. Refer to + https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html;> + Zero Length Arrays. + Any code relying on this extension should be modifed to ensure that + C99 flexible array members only end up at the ends of structures. + Please use the warning option + https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wflex-array-member-not-at-end;>-Wflex-array-member-not-at-end to + identify all such cases in the source code and modify them. + -- 2.31.1
