Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. Warning 'Variable lenght arrays in C++ are a Clang extension'
Forum Updated to NodeBB v4.3 + New Features

Warning 'Variable lenght arrays in C++ are a Clang extension'

Scheduled Pinned Locked Moved Solved General and Desktop
17 Posts 5 Posters 7.5k Views 3 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • I IgKh

    @MortyMars

    As far as the standards go, the size of everything that is allocated on the stack must be known at compile time. Various vendor extensions (and the C99 revision of the C standard, which has since deprecated it) allow breaking this rule for local arrays. This is generally perceived to be a bad idea, and should avoided, because:

    1. Stack space is typically more limited relative to the heap, allocating large arrays on the stack will increase chance of a stack overflow.
    2. It makes it harder for the compiler to verify that all reads and writes of local variables happen within the current stack frame. Writing outside of the frame (especially when it is guided by user input) is an extremely serious security vulnerability, and often a component in privilege escalation exploits.

    So yes - you really should allocate anything that you don't know the size of ahead of time on the heap, and ideally in a managed container. I'm not sure why a vector won't do for you - wanting a 2D array isn't an excuse, you can do a vector of vectors, a vector of structs, or allocate sufficient space and treat the one vector's data pointer as a row-by-row 2D array.

    JonBJ Offline
    JonBJ Offline
    JonB
    wrote on last edited by JonB
    #7

    @IgKh said in Warning 'Variable lenght arrays in C++ are a Clang extension':

    size of everything that is allocated on the stack must be known at compile time

    Just for the record, I don't see any evidence that the OP's code is inside any function or allocated on the stack. It might be, but it might just as well not be. If it is "global" scope (or for that matter class variables where no instance is ever stack-allocated) you still need to use constexpr (or equivalent) and not just const, because it needs to be a constant and not a variable, right?

    I 1 Reply Last reply
    1
    • JonBJ JonB

      @IgKh said in Warning 'Variable lenght arrays in C++ are a Clang extension':

      size of everything that is allocated on the stack must be known at compile time

      Just for the record, I don't see any evidence that the OP's code is inside any function or allocated on the stack. It might be, but it might just as well not be. If it is "global" scope (or for that matter class variables where no instance is ever stack-allocated) you still need to use constexpr (or equivalent) and not just const, because it needs to be a constant and not a variable, right?

      I Offline
      I Offline
      IgKh
      wrote on last edited by IgKh
      #8

      @JonB In OP's provided source code, they have in their ApprochWindow::createTableauFixes method:

      // Définition du tableau qui recevra les données de 'user_fix.dat'
      QString tabFix[NBLINES][7];
      

      This is definitely a stack allocation. But you are probably right - I don't believe that even globals and statics are allowed to be unsized in C++, if only for the technical reason that the linker needs to know how big the data segment is at link time at the very latest.

      JonBJ 1 Reply Last reply
      2
      • I IgKh

        @JonB In OP's provided source code, they have in their ApprochWindow::createTableauFixes method:

        // Définition du tableau qui recevra les données de 'user_fix.dat'
        QString tabFix[NBLINES][7];
        

        This is definitely a stack allocation. But you are probably right - I don't believe that even globals and statics are allowed to be unsized in C++, if only for the technical reason that the linker needs to know how big the data segment is at link time at the very latest.

        JonBJ Offline
        JonBJ Offline
        JonB
        wrote on last edited by JonB
        #9

        @IgKh
        I only looked at the 2-line screenshot :)

        And I don't think it's just a linker issue, it's a compiler one too. If you have, say in a class or for that matter on the stack,

        int array[non_constexpr_size];
        int next_variable;
        

        I don't think the compiler can even generate code since it does not know the offset of next_variable at compile-time. Or perhaps they figure a way because it's an optional "extension", but I can see the problem.

        I don't mean to be on your case! What you said is good. It's just that there are lots of/complex reasons why "vanilla" C/C++ has this restriction.

        MortyMarsM 1 Reply Last reply
        1
        • Christian EhrlicherC Christian Ehrlicher

          @MortyMars I wrote what you have to change.

          MortyMarsM Offline
          MortyMarsM Offline
          MortyMars
          wrote on last edited by
          #10

          @Christian-Ehrlicher said in Warning 'Variable lenght arrays in C++ are a Clang extension':

          I wrote what you have to change.

          Hi @Christian-Ehrlicher

          I obviously paid attention to your message and immediately tried out the suggested code.
          Unfortunately I don't get a ‘warning’ any more, but an ‘error’ preventing me from going any further.

          Capture d’écran 2024-10-24 à 15.44.24.jpg

          Unless there's something else behind your answer, which I didn't understand... ?!

          JonBJ 1 Reply Last reply
          0
          • MortyMarsM MortyMars

            @Christian-Ehrlicher said in Warning 'Variable lenght arrays in C++ are a Clang extension':

            I wrote what you have to change.

            Hi @Christian-Ehrlicher

            I obviously paid attention to your message and immediately tried out the suggested code.
            Unfortunately I don't get a ‘warning’ any more, but an ‘error’ preventing me from going any further.

            Capture d’écran 2024-10-24 à 15.44.24.jpg

            Unless there's something else behind your answer, which I didn't understand... ?!

            JonBJ Offline
            JonBJ Offline
            JonB
            wrote on last edited by
            #11

            @MortyMars
            Like it says, a constexpr must be assigned/set to a constant value, like 10. Assuming your nbrLignes is some variable it is not acceptable. It does not matter which way up you look at it/try to do it, you cannot declare an array with a size which is ultimately a variable, as per previous discussions.

            In a word, if nbrLignes or NBLINES or anything else is not a constant you cannot use it for the size of a plain array, because they require a fixed, constant size. You could new an array with a variable size, or you could use some non-fixed-size container such as std:array or QList/QVector if you want variability, but not a plain C-type like array[SIZE] as a local or global variable.

            1 Reply Last reply
            2
            • I IgKh

              @MortyMars

              As far as the standards go, the size of everything that is allocated on the stack must be known at compile time. Various vendor extensions (and the C99 revision of the C standard, which has since deprecated it) allow breaking this rule for local arrays. This is generally perceived to be a bad idea, and should avoided, because:

              1. Stack space is typically more limited relative to the heap, allocating large arrays on the stack will increase chance of a stack overflow.
              2. It makes it harder for the compiler to verify that all reads and writes of local variables happen within the current stack frame. Writing outside of the frame (especially when it is guided by user input) is an extremely serious security vulnerability, and often a component in privilege escalation exploits.

              So yes - you really should allocate anything that you don't know the size of ahead of time on the heap, and ideally in a managed container. I'm not sure why a vector won't do for you - wanting a 2D array isn't an excuse, you can do a vector of vectors, a vector of structs, or allocate sufficient space and treat the one vector's data pointer as a row-by-row 2D array.

              MortyMarsM Offline
              MortyMarsM Offline
              MortyMars
              wrote on last edited by
              #12

              @IgKh said in Warning 'Variable lenght arrays in C++ are a Clang extension':

              you can do a vector of vectors, a vector of structs, or allocate sufficient space and treat the one vector's data pointer as a row-by-row 2D arrayThank you ... for your help.

              Thank you @IgKh for your help

              As I said, I tried the vector of vectors solution, but I wasn't able to manage the matrix created, both in writing and reading the data, without running into access errors that prevented compilation.

              Furthermore, as I see it, a 2D array seems (wrongly, it seems) to be more appropriate.

              But I'm not definitively rejecting the idea of returning to vectors...

              JonBJ I 2 Replies Last reply
              0
              • JonBJ JonB

                @IgKh
                I only looked at the 2-line screenshot :)

                And I don't think it's just a linker issue, it's a compiler one too. If you have, say in a class or for that matter on the stack,

                int array[non_constexpr_size];
                int next_variable;
                

                I don't think the compiler can even generate code since it does not know the offset of next_variable at compile-time. Or perhaps they figure a way because it's an optional "extension", but I can see the problem.

                I don't mean to be on your case! What you said is good. It's just that there are lots of/complex reasons why "vanilla" C/C++ has this restriction.

                MortyMarsM Offline
                MortyMarsM Offline
                MortyMars
                wrote on last edited by
                #13

                @JonB said in Warning 'Variable lenght arrays in C++ are a Clang extension':

                I don't mean to be on your case! What you said is good. It's just that there are lots of/complex reasons why "vanilla" C/C++ has this restriction

                Thank you @JonB for these very clear explanations, even if I'm beginning to realiseund that I'm going to have to reconsider my choice of a 2D array... :-(

                1 Reply Last reply
                0
                • MortyMarsM MortyMars

                  @IgKh said in Warning 'Variable lenght arrays in C++ are a Clang extension':

                  you can do a vector of vectors, a vector of structs, or allocate sufficient space and treat the one vector's data pointer as a row-by-row 2D arrayThank you ... for your help.

                  Thank you @IgKh for your help

                  As I said, I tried the vector of vectors solution, but I wasn't able to manage the matrix created, both in writing and reading the data, without running into access errors that prevented compilation.

                  Furthermore, as I see it, a 2D array seems (wrongly, it seems) to be more appropriate.

                  But I'm not definitively rejecting the idea of returning to vectors...

                  JonBJ Offline
                  JonBJ Offline
                  JonB
                  wrote on last edited by JonB
                  #14

                  @MortyMars said in Warning 'Variable lenght arrays in C++ are a Clang extension':

                  As I said, I tried the vector of vectors solution, but I wasn't able to manage the matrix created, both in writing and reading the data, without running into access errors that prevented compilation.

                  Then you need to correct that. Code using vector-of-vector can be addressed just as much/in same way as array-of-array.

                  Vector-of-vector seems just as suitable as array-of-array for a two-dimensional array/container. (Assuming you are "in charge" of the data structure, not trying to make your structure correspond to something received from the outside world in a particular layout format.)

                  You can use an array-of-array, effectively, if that is what you want. You just cannot declare it as array[variable][variable]. You can do it e.g. with news and/or making it more like QString **array per the old C way. But I think people would recommend e.g. a std::array of std::array.

                  MortyMarsM 1 Reply Last reply
                  3
                  • MortyMarsM MortyMars

                    @IgKh said in Warning 'Variable lenght arrays in C++ are a Clang extension':

                    you can do a vector of vectors, a vector of structs, or allocate sufficient space and treat the one vector's data pointer as a row-by-row 2D arrayThank you ... for your help.

                    Thank you @IgKh for your help

                    As I said, I tried the vector of vectors solution, but I wasn't able to manage the matrix created, both in writing and reading the data, without running into access errors that prevented compilation.

                    Furthermore, as I see it, a 2D array seems (wrongly, it seems) to be more appropriate.

                    But I'm not definitively rejecting the idea of returning to vectors...

                    I Offline
                    I Offline
                    IgKh
                    wrote on last edited by
                    #15

                    @MortyMars I see how one can struggle with a vector of vectors, since you have to resize every element of the outer array prior to use.

                    But, since one dimension is dynamically size, and one isn't, you can mix and match to improve ergonomics.

                    Consider declaring tabFix as:

                    std::vector<std::array<QString, 7>> tabFix;
                    tabFix.resize(nbrLignes);
                    

                    This pre-allocates 7 empty QStrings for each line at runtime, so you access it just like a 2D array.

                    MortyMarsM 1 Reply Last reply
                    1
                    • JonBJ JonB

                      @MortyMars said in Warning 'Variable lenght arrays in C++ are a Clang extension':

                      As I said, I tried the vector of vectors solution, but I wasn't able to manage the matrix created, both in writing and reading the data, without running into access errors that prevented compilation.

                      Then you need to correct that. Code using vector-of-vector can be addressed just as much/in same way as array-of-array.

                      Vector-of-vector seems just as suitable as array-of-array for a two-dimensional array/container. (Assuming you are "in charge" of the data structure, not trying to make your structure correspond to something received from the outside world in a particular layout format.)

                      You can use an array-of-array, effectively, if that is what you want. You just cannot declare it as array[variable][variable]. You can do it e.g. with news and/or making it more like QString **array per the old C way. But I think people would recommend e.g. a std::array of std::array.

                      MortyMarsM Offline
                      MortyMarsM Offline
                      MortyMars
                      wrote on last edited by
                      #16

                      @JonB said in Warning 'Variable lenght arrays in C++ are a Clang extension':

                      Vector-of-vector seems just as suitable as array-of-array for a two-dimensional array/container. (Assuming you are "in charge" of the data structure, not trying to make your structure correspond to something received from the outside world in a particular layout format.

                      So I'm going to try my luck again with the vector-to-vector solution that I'd abandoned.
                      And I'll take the liberty of asking you again to correct my code as I go along... ;-)

                      Thanks again to everyone in the meantime.

                      1 Reply Last reply
                      0
                      • I IgKh

                        @MortyMars I see how one can struggle with a vector of vectors, since you have to resize every element of the outer array prior to use.

                        But, since one dimension is dynamically size, and one isn't, you can mix and match to improve ergonomics.

                        Consider declaring tabFix as:

                        std::vector<std::array<QString, 7>> tabFix;
                        tabFix.resize(nbrLignes);
                        

                        This pre-allocates 7 empty QStrings for each line at runtime, so you access it just like a 2D array.

                        MortyMarsM Offline
                        MortyMarsM Offline
                        MortyMars
                        wrote on last edited by
                        #17

                        @IgKh said in Warning 'Variable lenght arrays in C++ are a Clang extension':

                        Consider declaring tabFix as:

                        std::vector<std::array<QString, 7>> tabFix;
                        tabFix.resize(nbrLignes);
                        This pre-allocates 7 empty QStrings for each line at runtime, so you access it just like a 2D array

                        A huge thank you @IgKh

                        Your solution, which is a good compromise between what the community plebiscites and my personal stubbornness, works perfectly!!!!

                        No more error messages and even fewer errors, while still accessing my data naturally (IMHO).

                        1 Reply Last reply
                        1
                        • MortyMarsM MortyMars has marked this topic as solved on

                        • Login

                        • Login or register to search.
                        • First post
                          Last post
                        0
                        • Categories
                        • Recent
                        • Tags
                        • Popular
                        • Users
                        • Groups
                        • Search
                        • Get Qt Extensions
                        • Unsolved