On Thursday 2020-10-08 15:01, Phil Sutter wrote:
>Gcc-10 doesn't like the use of zero-length arrays as last struct member
>to denote variable sized objects.
On the contrary. It does not complain about the declaration of T x[0],
but about the write beyond the end of an array of size 0 (literally).
Such past-end writes are Undefined Behavior by the standard, and tools
like cov-scan (based on llvm I believe) report it just the same.
That's why C99 probably had to come up with "T y[]"; the array is now
of unspecified size rather than size 0. cov-scan agrees.
Since GCC has retained "T x[0]" as an extension, it would be a gcc bug
to warn about its own extension in conjunction with memcpy.
>The suggested alternative, namely to
>use a flexible array member as defined by C99, is problematic as that
>doesn't allow for said struct to be embedded into others.
Both T x[0] and T y[], in gcc, invoke the flexible scheme.
Both share the "embedding problem" - i.e. by using the flexible array,
you can accidentally access members of the surrounding struct.
gcc only complains about this when combining "T y[]" with C++ mode.
I find this to be an unusual choice and would suggest opening a bug.
The reason T x[0], when embedded, in C++, does not elicit a warning
is probably because it is already considered UB to access past-end-of-array
(see above); and I raise the hypothesis that the GNU extension of T x[0] is
actually only specified for C.
Anyway, gcc-10/C mode does not reject embedding (and a number of maintainers
have made it abundantly clear in the past they don't care if UAPI uses anti-C++
"features"). Nonreject example:
» cat x.c
struct a2 {
int x;
int z[];
};
struct m {
struct a2 y;
long q;
};
» gcc -Wall -std=c11 -c -w -v x.c
GNU C11 (SUSE Linux) version 10.2.1 20200825 [revision c0746a1beb1ba073c7981eb09f55b3d993b32e5c] (x86_64-suse-linux)
»
