Announcement

Collapse
No announcement yet.

Proposed GCC 12 Security Option Would Auto Initialize Automatic Variables

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Of all the potential problem in C++, the one I have never has any issues with, is problems due to uninitialized variables. Is it something other people see a lot?

    Comment


    • #12
      This looks like a feature only used for automatic variables (not sure what they are). It is probably not related to the programmer and how they write their code. It would probably still be valid to create variables without a default value even with this patch. As far as I have understood it at least, but I am no expert.

      Comment


      • #13
        Originally posted by Silverthorn View Post
        This looks like a feature only used for automatic variables (not sure what they are). It is probably not related to the programmer and how they write their code. It would probably still be valid to create variables without a default value even with this patch. As far as I have understood it at least, but I am no expert.
        Automatic variables is a fancy name for local variables (variables that are valid within the scope of a code block).
        In C and C++ such variables have an undefined value if not initialized. This patch allows the compiler to give all uninitialized variables a specific value. If you use this "feature", you will not be allowed to create variables without a default value, the compiler will give them a default value. It is not bad for a variable to have a default value (otherwise it will have a value as good as random) but I think the price to pay for such feature is too high IMO.

        Comment


        • #14
          The default is 'uninitialized'.
          You can control this behavior for a specific variable by using the variable attribute 'uninitialized' (*note Variable Attributes).
          So it seems that the forced initialization is not enabled by default and, even better, can be enabled only on selected variables.
          The reason why it's not enabled by default is

          With the option '-ftrivial-auto-var-init', all the automatic variables that do not have explicit initializers will be initialized by the compiler. These additional compiler initializations might incur run-time overhead, sometimes dramatically. This attribute can be used to mark some variables to be excluded from such automatic initialization in order to reduce runtime overhead. This attribute has no effect when the option '-ftrivial-auto-var-init' does not present.
          It also seems that this only applies to trivial initialization, which I guess means built-in types ony, not user types (for which the initialization with zeros or 'patterns' wouldn't make sense and they should be initialized by their default constructor anyway).

          As someone else said, I personally think that, instead of using this flag, one could (and should) enable warnings for uninitialized variables and decide case by case which of them need be initialized. But I'm sure there's a good reason for this option anyway.

          Comment


          • #15
            Originally posted by Serafean View Post

            Been there when it happened. Was a shitstorm at work :/
            https://www.hdm.io/tools/debian-openssl/
            Did OpenSSL really used UB to generate "random" numbers? I was pretty sure it was poorly coded but this is a new one.

            Comment


            • #16
              Originally posted by marios View Post

              Automatic variables is a fancy name for local variables (variables that are valid within the scope of a code block).
              In C and C++ such variables have an undefined value if not initialized. This patch allows the compiler to give all uninitialized variables a specific value. If you use this "feature", you will not be allowed to create variables without a default value, the compiler will give them a default value. It is not bad for a variable to have a default value (otherwise it will have a value as good as random) but I think the price to pay for such feature is too high IMO.
              I see, I did not know they had a special name for it.

              In that case it could really hurt performance a lot. For example code using a lot of memory might have a big hit on performance. There are many use cases where it is beneficial to allocate more memory than what is needed and initialize it as needed. Also a change like this would also cause bad behaviour on the CPU since it is constantly trying to optimise the use of its transistors. There would potentially both be cache misses and branch misses. This is not something that should be fixed in gcc. It should be corrected on hardware level to avoid any problems and performance impact altogether.

              Another aspect of a change like this might be developers starting to work around it causing more problems in the future than the few use cases it will help solving.

              Comment


              • #17
                Originally posted by david-nk View Post
                Zero would be a bad choice.
                I would agree that zero would be a bad choice for catching/identifying code bugs. However I do understand it could be a good result (by "accident") in that many of the code paths that fall into missing initialization(s) may have initialized the variable to zero in the first place except for bugs in the code. Whether it is 0xBBADF00D or 0xDEADBEEF, or some other well known identifier, any would seem to be better choices than zero so that the underlying error is fixed.

                Comment


                • #18
                  As several others have already said: use -Wuninitialized and treat warnings as errors. Fix your damn code!

                  IOW, this is a *terrible* idea. Except... the one thing that may well save it from being shot down right away is the usual "legacy codebase" argument.
                  But in practical terms, anyone who has a legacy codebase that they're still compiling without caring about the code quality (oh wait: it WAS an oracle dev suggesting this, right? :P) in the first place seems also unlikely to be paying enough attention to add this flag anyway, I expect.

                  Comment


                  • #19
                    It is not all local variables. But only plain old data: like int, float, or a pointer. So objects of classes are always initialized.

                    Having programmed a lot of C++, i think it is a good idea to have some default initialized value. Programmers expect that is initialized to zero, and many times in practice, it is, but it is not defined behaviour. The performance overhead is non-existent, it is just writing some default value. With todays CPU superscalar, you won't notice the performance difference. And the value of variables not initialized is "undefined". If you initialize to zero, this is also "undefined". If existing code breaks, it was broken already before.

                    Comment


                    • #20
                      Have a look here:
                      Uninitialised variables can cause problems. Simon Brand reminds us how complicated it can get.

                      Comment

                      Working...
                      X