New Safe C++ Proposal

[zapshe]

You'd be surprised. It's not uncommon for someone to find themselves trying to solve a problem while not knowing that they don't know what they're doing.

Yes, but obviously this can lead to all sorts of issues, UB not being the greatest threat. All sorts of user-input attacks are a direct consequence of such mistakes/not knowing what you're doing. UB is likely caught by a modern OS with no damage done, while an input attack is likely to go completely unnoticed until the damage is spotted.

I think there's an even better practice: don't use a language that can get you owned when processing untrusted input

So never use mySQL..

It would be highly unusual for a tokenizer to do any but the most rudimentary of sanitizations

Only the tokenizer would be able to track such a malicious attempt, as it could track oddities, such as how many parenthesis in a row it was receiving. It can impose a limit to the size of the input and other logical restrictions that couldn't be easily (or at least ideally since it would involve going through all the data you already went through) implemented elsewhere.

The only other method would be keeping track of the depth of your recursive calls. Even then, you'd end up guessing how deep you can go before overflowing.

It's not like C++ doesn't have features that will forbid you from screwing up.

Which has been my point the whole time. And if stack overflow becomes defined behavior, that's good (I'm not sure what effect that would have to performance, but I assume small).

[helios]

UB is likely caught by a modern OS with no damage done, while an input attack is likely to go completely unnoticed until the damage is spotted.

LOL, what are you saying? Vulnerabilities are precisely caused by UB.

So never use mySQL..

Never use MySQL because it's owned by Oracle.
SQL servers don't take untrusted input. They have logins.

Only the tokenizer would be able to track such a malicious attempt, as it could track oddities, such as how many parenthesis in a row it was receiving. It can impose a limit to the size of the input and other logical restrictions that couldn't be easily

None of that is within the purview of a tokenizer. Like I said, it's a simple conversion function. It shouldn't concern itself with anything other than converting sequences of characters into sequences of tokens.

Which has been my point the whole time.

You point the whole has been that you don't want to be prohibited from screwing up. You literally said "not saying don't add safer options, just don't prevent me from shooting myself in the foot".

[zapshe]

LOL, what are you saying? Vulnerabilities are precisely caused by UB

Sorry, I meant stack overflow will be caught with no damage done.

SQL servers don't take untrusted input. They have logins.

They don't take input from untrusted sources. It's up to the user to make sure the input is safe. SQL will happily delete everything if malicious input tells it to do so.

It shouldn't concern itself with anything other than converting sequences of characters into sequences of tokens.

Depends on the programmer, I would certainly put it there. It would be completely inefficient to add checking anywhere else, and there's a lot of checks you may want to do.

You point the whole has been that you don't want to be prohibited from screwing up. You literally said "not saying don't add safer options, just don't prevent me from shooting myself in the foot".

Where's the contradiction? Add the safer options, but also don't prevent me from shooting myself in the foot.

I'll choose when I wanna use the safer options or not. I've been repeatedly saying C++ has safe options and should continue to add more. What I'm saying is don't remove my ability to code dangerously should I choose to do so.

A "safe" language cannot permit code that could potentially lead to UB, even if it's perfectly safe when coded right. That would ruin C++ in my humble opinion.

If you write a language designed for safety, sure have unsafe blocks. I don't think badly of Rust at all. But C++ is not Rust and, I would argue, has nothing to gain from becoming copy of Rust. Rust already exists!

[helios]

But C++ is not Rust and, I would argue, has nothing to gain from becoming copy of Rust. Rust already exists!

It doesn't need to become a copy of Rust. Rust for example doesn't have OO. What it does need to do is enforce safety by default. I fear it may fade into irrelevance otherwise. They can make the transition as gradual as they want, but it does need to happen.