Historically, GCC has always preferred to behave by default as a compiler for the "extended" GNU dialects of C or C++ respectively. This situation is much older than C++11. As far back as GCC 1.21 circa 1988, GCC provided extensions (including zero-length arrays) that were not in the forthcoming initial C standard (ANSI C / C89), and enabled them by default. Clearly Stallman felt that his extensions made for a better language than the one defined by the standard, and wanted to encourage the use of his "GNU C" dialect. He did include the `-pedantic` option to revert to plain ANSI C, but the slightly derogatory name suggests that he didn't really encourage its use. These extensions, and others, eventually carried over into C++, so that now GCC by default is a compiler for the "GNU C++" dialect (which still includes zero-length arrays), and not for ISO C++.

I don't know whether today's GCC team has similar strong feelings about the GNU dialect's superiority, or if the "GNU dialect by default" behavior just remains for compatibility.

But in any case, the fact remains that `g++ foo.cc` does NOT invoke a compiler of the ISO C++ language, and no official documentation claims that it does. And `g++ -std=c++23 foo.cc` is not quite doing so either; it follows ISO C++ more closely, but still allows GNU extensions where they're not in direct conflict with ISO C++. (Here "direct conflict" wouldn't simply be "ISO C++ forbids it", but rather "ISO C++ allows this but defines it as doing something else".) So indeed, to get something that really purports to be an ISO C++ compiler, issuing all diagnostics required by the standard, you need `g++ -std=c++23 -pedantic`.

I agree that this fact is not well known by new users, and one could wish that GCC would advertise it more prominently, but the ISO committee has no say in that.

In terms of ISO C++, which, as all agree, forbids zero-length arrays, the user in your question had a syntactically invalid program that ought to have triggered a diagnostic. But by running `g++ foo.cc`, the user wasn't compiling ISO C++ at all, but was (probably unwittingly) compiling GNU C++. And from the standpoint of GNU C++, in which zero-length arrays are a perfectly legal and fully supported language feature, the user had a syntactically *valid* program that simply had a runtime bug, in that it accessed elements beyond the length of the array (i.e. zero). (It would be flagged at compile time by `-O2 -Wall`.)

Zero-length arrays were somewhat useful in GNU C prior to the introduction of flexible array members in C99. You are certainly free to believe that they are a "trap for beginners" and ought not to have been included in the GNU dialects in the first place, but you'll have to time-travel back to 1988 and take that up with Stallman. You could also argue that they ought to be removed now, but since there does exist GNU C and/or GNU C++ code that deliberately uses them, removing them now would break backward compatibility. Anyhow, as before, none of this has anything to do with the ISO committee.


> On May 1, 2026, at 13:16, Maciej Polański via Std-Discussion <std-discussion_at_[hidden]> wrote:
>
> That's valuable input! So there is a consensus that the zero-size array is erroneous.
>
> I also discovered that this is explicitly prohibited by [dcl.init.aggr] 9.5.2.10.
> "An array of unknown bound shall not be initialized with an empty braced-init-list {}"
> https://eel.is/c++draft/dcl.init.aggr#10
>
> I wonder if there is a rationale behind keeping zero-size arrays as the default. My guess is that it's a legacy of the initial C++11 implementations.
>
> What concerns me:
> 1. C/C++ is seen as difficult to learn by young programmers.
> 2. The implementation of arrays is effective, yet quite unusual compared to other languages, and it can be difficult to understand at first.
> 3. And yet some compilers have a trap for beginners, which is something to be aware of. Silent acceptance of obvious errors can hinder subsequent debugging attempts.
>
> I thought something should be changed, but now I've lost my confidence.
>
> Thanks,
> Maciej
>
> W dniu 27.04.2026 o 20:10, Nate Eldredge pisze:
>> GCC and Clang only claim standard compliance when -pedantic is used, and with this option, they both issue a diagnostic (an error for GCC, a warning for Clang). So I don't think your proposed text would require them to change anything.
>>
>> I wouldn't say they are treating it as "legal". They both provide zero-length arrays as a clearly documented extension, which they readily acknowledge is non-standard. A user who wants to avoid such extensions and receive all standard-mandated diagnostics should know to use -pedantic.
>>
>> You may very well think that the -pedantic behavior should be their default, to avoid such instances of confusion, and you could take that up with their developers, but it's outside the jurisdiction of the standard.
>>
>>> On Apr 27, 2026, at 11:51, Maciej Polański via Std-Discussion <std-discussion_at_[hidden]> wrote:
>>>
>>> Dear Group,
>>>
>>> Please let me know if the world needs this fix and if it could count as an editorial. So:
>>>
>>> The following variable declaration is not allowed and should result in an error:
>>> int arr[];
>>> However, due to an unclear wording in The Standard, the following statement is legal on many compilers, though UB:
>>> int arr[]{};
>>> I'll be glad to be proved wrong if there's a legal use for `int arr[]{}`.
>>>
>>> The current "state of the art" is that GCC and Clang allow a zero-sized array if the bounds are omitted and followed by an empty initializer. MSVC is more cautious and prevents developers from experiencing the consequences of their errors. I suppose the authors of all the compilers think they are compliant on this issue.
>>> https://godbolt.org/z/jbbcnqP9K
>>>
>>> In my opinion, the problem lies in interpreting the unfortunate wording of The Standard [decl.array] "9.3.4.5 Arrays - 7" without proper context:
>>> "An array bound may also be omitted when an object (but not a non-static data member) of array type is initialized and the declarator is followed by an initializer"
>>> https://eel.is/c++draft/dcl.decl#dcl.array-7
>>> This paragraph does not explicitly exclude empty initializers. In the case of arrays, "empty" means "nothing," which may result in undefined behavior (UB).
>>>
>>> But, in my opinion, the compiler should interpret the paragraph above in the context of the following:
>>> 1. "[decl.array] 9.3.4.5 Arrays - 1" That explicitly states that the array bound "N shall be greater than zero".
>>> 2. "[dcl.init.general] 9.5.1 General - 16.5" That describes use of an initializer for an array and requires "1 <= i <= k," where k is the initializer size.
>>>
>>> In my opinion, the solution could be as simple as rewording "followed by an initializer" to "followed by a non-empty initializer."
>>>
>>>
>>> This issue surfaced during, not directly related to it, StackOverflow discussion:
>>> https://stackoverflow.com/questions/78941074/accessing-and-modifying-array-elements/78941410#78941410
>>> Among other mistakes, the author used a zero-size array. As the StackOverflow question showed, this mistake happens among beginners. Perhaps some think that zero-size arrays are self-extending, as many scripting languages have this feature. Therefore, it could be helpful to prevent zero-size array cases.
>>>
>>> The arguments for classifying this as an editorial are as follows:
>>> It is obvious that no zero-size arrays exist.
>>> Rule "Unclear writing, when the intention of the text in question is well-known to the committee, but the presentation could be clearer".
>>> There should also be no impact on existing programs, as those using zero-size are likely already broken.
>>> Against:
>>> This removes UB, which may affect some really exotic cases. Such changes may require formal paper.
>>>
>>> Even though I have a hard time accepting criticism, I welcome all opinions :)
>>>
>>> Maciej Polański
>>> MaciejPolanski75_at_[hidden]
>>>
>>> --
>>> Std-Discussion mailing list
>>> Std-Discussion_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion