Announcement

Collapse
No announcement yet.

Proposed GCC 12 Security Option Would Auto Initialize Automatic Variables

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

  • coder
    replied
    Originally posted by arQon View Post
    As several others have already said: use -Wuninitialized and treat warnings as errors. Fix your damn code!
    If only it were that simple!

    Originally posted by arQon View Post
    IOW, this is a *terrible* idea.
    It's not mutually-exclusive, is it? I guarantee there are cases where -Wuninitialized will give a false-negative! Why not wear a belt and suspenders?
    Last edited by coder; 25 February 2021, 03:35 AM.

    Leave a comment:


  • coder
    replied
    I just hope the compiler emits something that tools like valgrind can use to track when such variables get used before they've been properly assigned. Then, I'd be 100% onboard with this feature.

    Leave a comment:


  • coder
    replied
    Originally posted by carewolf View Post
    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?
    There are cases where you don't have a meaningful value, at the point of definition. So, you're faced with a dilemma of either zero-initializing it and preventing the compiler from warning you of possible use before it's been properly-assigned, or hoping to benefit from such warnings while incurring the risk that the compiler doesn't catch it and you end up with some unpredictable behavior at runtime. Since I try to write my code semantically, I'm somewhat allergic to using bogus initializers, just for the sake of initializing to something.

    C++11 lambdas enable a style where you can often avoid this situation, but I sometimes wonder if such lambdas could incur runtime overhead, and it can confuse people reading your code who aren't used to that style. It does feel like a slight abuse of the lambda mechanism, but still preferable to bogus initializers.

    Leave a comment:


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

    Leave a comment:


  • wkleunen
    replied
    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.

    Leave a comment:


  • arQon
    replied
    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.

    Leave a comment:


  • CommunityMember
    replied
    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.

    Leave a comment:


  • Silverthorn
    replied
    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.

    Leave a comment:


  • gufide
    replied
    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.

    Leave a comment:


  • klapaucius
    replied
    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.

    Leave a comment:

Working...
X