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