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

[norm]

On Wednesday, 14 December 2022 at 23:56:53 UTC, 
areYouSureAboutThat wrote:
> On Wednesday, 14 December 2022 at 23:29:00 UTC, 
> areYouSureAboutThat wrote:
>>
>> That wasn't posted in the context of trusting code, but rather 
>> in the context of a thread where someone mentioned that OOP is 
>> not suited to building containers. I just posted that link to 
>> MS containers to refute that assertion.
>>
>
> Oops. A vorrection to my response above, as I mis-read that 
> link (thinking it was pointing to C# containers).
>
> the correct answer to the question posed to me:
>
> "Earlier you posted this link: 
> https://learn.microsoft.com/en-us/dotnet/csharp/misc/cs0227
>  Why do you 'trust' the standard library and VM of C# to be 
> 'safe'?"
>
> I don't. But that is not the point I was trying to make.
>
> That link was to demonstrate, that in C# I cannot get untrusted 
> code into my code without my explicately telling the compiler I 
> want it. i.e. just marking C# code as unsafe is not enough. You 
> *also* need to compile with the unsafe option - it cannot just 
> sneak in just cause someone marked it as unsafe.
>
> This is not the case in D, as per my previous post.
>
> Anyway....

At the very least D should be @safe by default. Slapping a @safe 
at the top of main isn't good enough, I know it is easy but 
programmers forget or simply do not know. Out of box experience 
is vital, @safe by default is part of that IMO if you really want 
to market as a Rust alternative.

Having said that, I personally don't think Rust is a good 
approach to SW engineering. It solves one problem well, but that 
solution negatively impacts other aspects of SW development, some 
of which are not related to the memory problem. Rust does other 
things really well too but they are often masked by this 
everything is a nail approach for average developers.

Most security hacks (that I know of) are not due to C array 
overruns. Those headliners that usually come from C/C++ code 
written >10yrs ago. The majority of security breaches are due to 
human activities, people clicking on fake email links, sharing 
passwords, leaving computers unlocked, incorrect server and 
database configuration etc. Rust and @safe will not solve these 
real world problems.