Typical security issues in C++: why the GC isn't your enemy

Timon Gehr timon.gehr at gmx.ch
Tue Dec 6 23:58:08 UTC 2022


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)


More information about the Digitalmars-d mailing list