3

With the following code in mind:

int main()
{
    int n = 3;
    int arr[n] = { 1, 2, 3 };
}

GCC properly errors out in C99 mode error: variable-sized object may not be initialized and clang gives the same error in C++ mode. However in C++ mode, GCC doesn't complain. This would lead me to believe that it's possibly an extension that's not documented on their C extensions VLA page. I couldn't find a matching bug report either. Can anyone verify if this is an extension or if there's an existing bug report?

Billy ONeal
  • 104,103
  • 58
  • 317
  • 552
  • I fail to see this feature as distinct from VLAs. If it has VLAs, I'd consider it a bug to NOT have this feature. – Mooing Duck Oct 27 '14 at 23:31
  • Is this really a VLA? In C++, if an expression can be evaluated at compile-time, it **is** evaluated at compile-time. (Yes, I'm arguing that your `n` may actually well be a `constexpr`, although I'm not sure.) – The Paramagnetic Croissant Oct 27 '14 at 23:31
  • Are you sure that [gcc doesn't complain](http://ideone.com/tjBkPd)? – Marco A. Oct 27 '14 at 23:32
  • @Marco Interesting, maybe it's a regression. In GCC 4.9 and trunk it doesn't give an error. –  Oct 27 '14 at 23:33
  • @MarcoA.: [No, it does not.](http://coliru.stacked-crooked.com/a/ed5d7034122ecf5b) Unless you ask for it... – Deduplicator Oct 27 '14 at 23:42
  • Fair enough; added the C++ tag back. But leaving the C tag 'cause people who hang around the C tag are more likely to be familiar with C VLA semantics given that it is a C feature. – Billy ONeal Oct 27 '14 at 23:55
  • Variable Length Arryas (VLAs) have never been a part of standard C++ (upto C++11). In standard C, VLAs can't have aggregate-style initialization (even in C99). So this has to be an extension (documented or not) GCC enables all sorts of extensions by default that you won't know whether something is deliberate or *accidental* extension and they will respond after 2 years (if you are lucky) for any bug reports ;-) – P.P Oct 28 '14 at 00:21

1 Answers1

3

This new behaviour is actually mentioned in as I suspect may be correlated with GCC 4.9 release notes:

G++ supports C++1y variable length arrays. G++ has supported GNU/C99-style VLAs for a long time, but now additionally supports initializers and lambda capture by reference. In C++1y mode G++ will complain about VLA uses that are not permitted by the draft standard, such as forming a pointer to VLA type or applying sizeof to a VLA variable. Note that it now appears that VLAs will not be part of C++14, but will be part of a separate document and then perhaps C++17.

Note that default standard mode for C++ is still gnu++98/gnu++03 for this release.

Grzegorz Szpetkowski
  • 36,988
  • 6
  • 90
  • 137
  • 2
    The samples were not in C++1y/14, this reproduces with C++98 and C++11 – Marco A. Oct 27 '14 at 23:44
  • @MarcoA.: You mean, nobody asked GCC to be conforming. It's no more conforming in C++98/11. – Deduplicator Oct 27 '14 at 23:48
  • @Deduplicator how come? This is kind of new to me – Marco A. Oct 27 '14 at 23:50
  • That's the reason one has to go all-out `-std=c++xy -pedantic` (or better `-Wall -Wextra -pedantic-errors -std=c++xy`). – Deduplicator Oct 27 '14 at 23:52
  • @MarcoA. GCC by default is far more permissive than the standard. It accepts a lot of things that should be in fact rejected. – The Paramagnetic Croissant Oct 27 '14 at 23:52
  • If this is the case, then I'm assuming it's referring to runtime-sized arrays which clang doesn't support. I don't see it under GCC's [technical specifications status](https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2014). –  Oct 27 '14 at 23:54
  • 3
    @remyabel: That's because C++ doesn't have VLAs. (Arrays of runtime bound were moved into a separate TS and aren't part of C++14) – Billy ONeal Oct 27 '14 at 23:56
  • @Billy On further inspection it appears arrays of runtime bound are covered by [n3662](http://www.open-std.org/JTC1/sc22/WG21/docs/papers/2013/n3662.html). I guess this is just some weird GCC extension. –  Oct 28 '14 at 00:04
  • 1
    @remyabel: They were temporarily added into the C++14 working paper and then extracted into a separate TS prior to C++14's standardization, and aren't in C++14 proper. (That said it is likely that the behavior in the TS (and in C++17) will be very similar) – Billy ONeal Oct 28 '14 at 00:05
  • @TheParamagneticCroissant: "*It accepts a lot of things that should be in fact rejected.*" -- Perhaps more accurately, it accepts a lot of things for which the standard requires a diagnostic. I believe the only case where the standard actually requires a source file to be *rejected* is `#error`. For other errors, it only requires a diagnostic, which may be a non-fatal error. (Disclaimer: I know that's the case for C; I *think* it's the case for C++.) – Keith Thompson Oct 28 '14 at 00:18