On Tuesday, 6 December 2022 at 10:03:24 UTC, Arjan wrote:
> On Monday, 5 December 2022 at 23:58:58 UTC, Timon Gehr wrote:
>> On 12/5/22 20:57, H. S. Teoh wrote:
>> Default initialization does not even fix all initialization issues, it just makes them reproducible. Anyway, I think neither default initialization nor uninitialized variables are the right solution, but you kind of have to do it this way given how scoping works in C++ and in D.
>
> Now I'm curious, what, in you opinion, would be best for initialization?
> How is C++/D scoping limiting in this?

Compiler can do control flow analysis, so they can force you to initialize things before you use them. This is the right solution to that problem.

On Monday, 5 December 2022 at 23:58:58 UTC, Timon Gehr wrote:
> On 12/5/22 20:57, H. S. Teoh wrote:
>> Similarly, D's initialized-by-default variables are often touted as a
>> big thing, but overall issues with uninitialized variables only
>> constitute about 1% of the total issues.
>
> Default initialization does not even fix all initialization issues, it just makes them reproducible. Anyway, I think neither default initialization nor uninitialized variables are the right solution, but you kind of have to do it this way given how scoping works in C++ and in D.

I wouldn't see lack of default initialization as a source of bugs, rather an attack vector.  It isn't a concern that there are uninitialized data pointing to garbage causing your program to do something wild/unexpected.  The concern is when it might point to useful information.

On 12/6/22 19:24, Iain Buclaw wrote:
> On Monday, 5 December 2022 at 23:58:58 UTC, Timon Gehr wrote:
>> On 12/5/22 20:57, H. S. Teoh wrote:
>>> Similarly, D's initialized-by-default variables are often touted as a
>>> big thing, but overall issues with uninitialized variables only
>>> constitute about 1% of the total issues.
>>
>> Default initialization does not even fix all initialization issues, it just makes them reproducible. Anyway, I think neither default initialization nor uninitialized variables are the right solution, but you kind of have to do it this way given how scoping works in C++ and in D.
> 
> I wouldn't see lack of default initialization as a source of bugs, rather an attack vector.  It isn't a concern that there are uninitialized data pointing to garbage causing your program to do something wild/unexpected.  The concern is when it might point to useful information.

True, that's a concern (default initialization does fix _some_ issues around initialization).

On 12/6/22 11:03, Arjan wrote:
> On Monday, 5 December 2022 at 23:58:58 UTC, Timon Gehr wrote:
>> On 12/5/22 20:57, H. S. Teoh wrote:
>> Default initialization does not even fix all initialization issues, it just makes them reproducible. Anyway, I think neither default initialization nor uninitialized variables are the right solution, but you kind of have to do it this way given how scoping works in C++ and in D.
> 
> Now I'm curious, what, in you opinion, would be best for initialization?

Ideally you just eliminate those cases where a programmer feels like they have to leave a variable uninitialized. The whole concept of "uninitialized variable" does not make a whole lot of sense from the perspective of a safe high-level programming language.

> How is C++/D scoping limiting in this?
> 

Variables are scoped within the innermost block that they are declared in. Languages like Python that don't have block-local scoping just don't have this particular problem (there's plenty of things to dislike about Python, but this is something it got right I think):

```python
# note there is no x declared here
if cond:
    x = f()
else:
    x = g()
print(x)
```

A particularly egregious case is the do-while loop:

```d
do{
    int x=4;
    if(condition){
        ...
        x++;
    }
    ...
}while(x<10); // error
```

Just... why? x)

Very good post!

On 12/5/2022 11:57 AM, H. S. Teoh wrote:
> Similarly, D's initialized-by-default variables are often touted as a
> big thing, but overall issues with uninitialized variables only
> constitute about 1% of the total issues.

True, I did not encounter this bug that often. But, and this is a big but, they cost me a *lot* of time to find, sometimes days. This is because when you'd close in on where the bug was, it would dance away. The way it exhibits is totally dependent on everything else in the program.

That's why it's a very serious problem.

On 12/5/2022 11:57 AM, H. S. Teoh wrote:
> Most interesting point here is that the largest category of bugs is
> use-after-free bugs, constituting 34% of the reported issues.  (Arguably
> we should include "object lifecycle/lifetime" in this category, but I
> think those refer to bugs in the JS implementation. In any case, it
> doesn't change the conclusion.)  This is strong evidence that memory
> management is a major source of bugs, and a strong argument for GC use
> in application code.

I'm a bit surprised at this, but maybe I shouldn't. C++ doesn't have a good feature set to prevent use-after-free.


> D's bounds checks are often touted as a major feature to prevent issues
> with buffer overflow and out-of-bounds accesses.  Interestingly, "buffer
> overflow" and "out of bounds..." add up only to about 14% of the total
> issues.  Nothing to sneeze at, but nonetheless not as big an issue as
> use-after-free bugs.

The language here is C++, and C++ has touted that if you use the latest C++ features, you'll have fewer bounds problems. I suspect that is the cause of the reduction. With C code, the percent is a lot higher.

On 12/5/2022 11:57 AM, H. S. Teoh wrote:
> Most interestingly, "double free" only has 3 counts of the total, less
> than 1%, compared with "use after free", which constitute the largest
> category of issues.  This seems to suggest that it's not memory
> management in general that's necessarily problematic, but it's keeping
> track of the *lifetime* of allocated memory.  One could say that this is
> proof that lifetime is a complex problem. But again it's a strong
> argument that the GC brings a major benefit: it relieves the programmer
> from having to worry about lifetime issues.  You can instantly be freed
> from 34% of security issues, if the above numbers are anything to go by.

This is a good interpretation of the results.

On 12/5/2022 3:58 PM, Timon Gehr wrote:
> Default initialization does not even fix all initialization issues, it just makes them reproducible.

As I mentioned in another post, making them reproducible is a huge deal. Leaving variables uninitialized is Heisenbug City. Testing finds the reproducible ones, not the Heisenbugs.