Is there anyway to make this safe?

Everyone says how unsafe C is. Is that because it gives the programmer too much freedom and most programmers are shit? Or is it because there is something fundamentally unsafe with the language which no c/c++ expert could ever fix.

Attached: serveimage.png (1200x1349, 69K)

Other urls found in this thread:

youtube.com/watch?v=aDQDL-l1nxw
archive.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf
eiffel.org/doc/eiffelstudio/Melting_Ice_Technology
dev.eiffel.com/Eiffel_Compilation_Explained
twitter.com/AnonBabble

>Is that because it gives the programmer too much freedom and most programmers are shit?
yes
>Or is it because there is something fundamentally unsafe with the language which no c/c++ expert could ever fix.
probably not, but there's nothing wrong with trying to mitigate the failures of inferior programmers by getting them to use a more inherently secure/safe language, such as a functional language

>Or is it because there is something fundamentally unsafe with the language which no c/c++ expert could ever fix.
The answer is: You're brainlet.

The language doesn't prevent you from writing stuff that doesn't work, like dereferencing a NULL pointer, or writing outside the range of an array, or using something after freeing it.
This is what they call unsafe, and by the power of mental gymnastics, makes the whole language unsafe.

>without fixing the language itself

Take a look at this talk by Kees Cook, a security engineer that works on the linux kernel. In this talk he talks about how to make C safer, I think that it can be applied to c++ too. Ignore the Rust evangelists in the comments.

>youtube.com/watch?v=aDQDL-l1nxw

>Is that because it gives the programmer too much freedom
>superscalar architecture
>high level language with optimizations that can cause user "freedom" to become undefined behavior
>can't even control the memory layers associated with caching
>freedom

honestly, if people, like GNU, would stop sperging about annex K, that would go a long way in making it easier to write decently safe C code.

>Or is it because there is something fundamentally unsafe with the language which no c/c++ expert could ever fix.
Are you talking about changing the languages themselves or following proper practice and hygiene?

You remove pointers.

Nothing about C++ is inherently unsafe (there are no bugs in the spec and very few if any in the compiler that don't get caught in regression testing). People whining about safety and UB don't understand what user error is imo. You can avoid a lot of headache by just following modern C++ practices if you're not comfortable with the freedoms. There are also plenty of dynamic and static code analyzers available to make sure you're not doing anything retarded.

Talking about safety of programs in general...

archive.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf

No one is safe, ever, unless you do everything (even hardware) by yourself.

It's very easy to make C++ safe. Do not ever use raw pointers, new, or delete.

Sure, but if you start from the assumption of defective hardware, there's not much you can do from there.

Avoiding C features. C++ can be pretty safe, although it has some weird quirks in the specs inherited from C.

Avoiding raw pointers and using them instead of arrays should be enough. Std::array and std::vector have bound checks and associated size field.

Implicit integer retyping is massive clusterfuck in C. Use std casts.

Resource scoping model is ok in C++. Rust shills will tell you that C++ doesn't check use after move (clang-tidy does btw), but the pattern in C++ is to almost never move, pass r-value reference and let the leaf functions copy the allocation instead of move.

Concurrency bugs because something isn't thread/async safe... yeah this is dominant win for Rust. Just design your shared concurrent state very carefully.

>programmers are shit?
unironically yes

>can't even control the memory layers associated with caching
Name 1 (one) language

not that user, but there are tricks in assembly that are applyable in C as well (e.g. to prefetch memory for next loop iteration at the end of the loop body)

>too much freedom
If the grill is removed from a fan, exposing the blades, is it best to describe that situation as the access or use of the fan is "more free"? Additionally, what if that fan is in a dark room with low visibility? "Freedom" isn't the prominent issue.

Attached: gray-lasko-box-fans-b20540-64_1000.jpg (1000x1000, 230K)

But you get better airflow without the grill so it's a more efficient system and maintenance, like cleaning the blades, is easier without the grill so it's a better maintained system. Only a brainlet would walk into the spinning blades.

If there were more spinning blades in the world maybe there would be fewer brainlets.

Performance is overrated.

Some OOP enthusiasts here might find the Eiffel approach to safety interesting.

Attached: Touch_of_Class.jpg (370x499, 26K)

Interesting. So it compiles safe C code essentially?

eiffel.org/doc/eiffelstudio/Melting_Ice_Technology
dev.eiffel.com/Eiffel_Compilation_Explained

Sorry but Im not seeing what makes it safe.

I can't contort myself right now into a shallow comprehension of technology perspective. You might find some revelation in the preface of one of the books.