1

I´ve been happily coding with CLion to create a project for University whilst using C99 standard. As of today variable lengths for array declaration won`t work. Does anyone have any ideas why? Code:

int main() {
    // to allow debugging with CLION
    setbuf(stdout, 0);
    int number = 5;
    int myarray[number];
    return 0;
}

CMakeLists.txt

project(PG1 C)

set(CMAKE_C_STANDARD 99)

add_executable(PG1 main.c ...)

Error is:

C:\...\PG1\main.c(10): error C2057: Constant value required
C:\...\PG1\main.c(10): error C2466: Declaration of array with constant size 0 not possible
C:\...\PG1\main.c(10): error C2133: "myarray": unknown size
NMAKE : fatal error U1077: "C:\PROGRA~2\MICROS~2\2019\BUILDT~1\VC\Tools\MSVC\1427~1.291\bin\Hostx86\x86\cl.exe": Return-Code "0x2"
Stop.
NMAKE : fatal error U1077: ""C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.27.29110\bin\HostX86\x86\nmake.exe"": Return-Code "0x2"
Stop.
NMAKE : fatal error U1077: ""C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.27.29110\bin\HostX86\x86\nmake.exe"": Return-Code "0x2"
Stop.
NMAKE : fatal error U1077: ""C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.27.29110\bin\HostX86\x86\nmake.exe"": Return-Code "0x2"
Stop.
dbush
  • 205,898
  • 23
  • 218
  • 273
Florian
  • 59
  • 8

2 Answers2

2

CLion is using MS Visual Studio 2019 as the underlying compiler. MSVC is not a fully compliant C compiler, and in particular it does not support variable length arrays.

You would have to use gcc or clang to get support for VLAs.

dbush
  • 205,898
  • 23
  • 218
  • 273
1

As of today variable lengths for array declaration won`t work. Does anyone have any ideas why?

OP's compiler is not C99 compliant (which first specified Variable-length_array - VLA support), not compliant with later versions that optionally support VLA, nor does the compiler have that enabled as an extension.

is there any way how i can verify the compiler version?

Code could test various macros to see if VLAs are supported by the version of the compiler.

#if defined __STDC__ && defined __STDC_VERSION__ && (__STDC_VERSION__ == 199901)
  #define VLA_SUPPORTED 1
#elif defined __STDC__ && defined __STDC_VERSION__  && (__STDC_VERSION__ >= 201112)  && \
    (__STDC_NO_VLA__ != 1)
  #define VLA_SUPPORTED 1
#else 
  #define VLA_SUPPORTED 0
#endif
chux - Reinstate Monica
  • 143,097
  • 13
  • 135
  • 256
  • Note that even C99 never actually imposes any requirements on anything implementation do with code that uses VLAs. Given `int foo[x];`, almost any realistic implementations would overflow the stack if `x` is too large. Presumably the authors of the Standard expected that implementations probably wouldn't usefully process the code if `x` is 2,000,000,000 but would process it usefully if `x` is 2. Nothing in the Standard offers any hint about what range of `x` a quality implementation should seek to support, much less any requirement that any implementations handle an `x` value of even 2. – supercat Jan 01 '21 at 20:01
  • @supercat "Nothing in the Standard offers any hint about what range of `x` a quality implementation should seek" --> Perhaps an upper range is hinted. With `int foo[x];`, I'd expect the `sizeof foo` to be within `size_t` range. That does imply an upper bound for `x`. – chux - Reinstate Monica Jan 01 '21 at 22:04
  • Certainly on an implementation with a 32-bit `int` and `size_t`, it would be unlikely that `int foo[x];` would behave usefully if `x` is 0x40000002, but I don't think that implies anything about whether the construct should be expected to work if e.g. x is 50000, nor whether a system that traps on stack overflow should be expected to trap if `x` is 0x40000002, rather than e.g. silently allocating 0x40000002\*4u [i.e. eight] bytes. – supercat Jan 01 '21 at 22:37
  • @supercat I read your comments as moving about the various issues of VLAs and unclear how those relate then to VLA existence on a select implementation. OP's question is about VLA existence and this answer focuses on that, not VLA usefulness, vulnerabilities nor quality of implementation. – chux - Reinstate Monica Jan 01 '21 at 23:07
  • If one were to change an implementation which rejects VLAs so that it would silently accept them but generate nonsensical code, such behavior would be conforming, but I would nonetheless regard it as less useful than rejection of the non-supported construct. Useful support has always been optional, and I regard C99's requirement that conforming implementations accept VLA-based programs that they can't process usefully as silly and worse than useless. – supercat Jan 01 '21 at 23:11
  • A major problem with VLAs as compared with other quality-of-implementation issues is that most of the latter could be addressed by applying the principle that in situations where existing implementations for various platforms and purposes would consistently support a construct, people seeking to write implementations for similar platforms and purposes should do likewise when practical, without regard for whether the Standard would require them to do so. For VLAs, however, there wasn't a large body of precedent as there had been for many other features. – supercat Jan 01 '21 at 23:16
  • @supercat Sigh, comments. reads more like a tutorial/rant about the usefulness and limitations of VLAs, than a comment related to directly to detecting their existence in an implementation. Do you have a comment about how to detect VLA existence as asked by OP? – chux - Reinstate Monica Jan 01 '21 at 23:28