←back to thread

177 points signa11 | 6 comments | | HN request time: 0s | source | bottom
Show context
Arch-TK ◴[] No.42160944[source]
I have memorised the UB rules for C. Or rather, more accurately, I have memorised the subset of UB rules I need to memorise to be productive in the language and am very strict in sticking to only writing code which I know is well defined (and know my way around the C standard at a level where any obscure code I sometimes need to write can be verified to be well defined without too much hassle). I think Rust may be difficult But, if I forget something, or make a mistake, I'm screwed. Yes there's ubsan, there's tests, but ubsan and tests aren't guaranteed to work when ub is involved.

This is why I call C a minefield.

On that note, C++ has such an explosion of UB that I don't generally believe anyone who claims to know C++ because it seems to me to be almost infeasible to both learn all the rules, or at least the subset required to be productive, and then to write/modify code without getting lost.

With rust, the amount of rules I need to learn to understand rust's borrow checker is about the same or even less. And if I forget the rules, the borrow checker is there to back me up.

I still think that unless you need the performance, you should use a higher level language which hides this from you. It's genuinely easier to think about.

That being said, writing correct rust which is going to a: work as I intended and b: not have UB is much less mentally taxing, even when I have to reach for unsafe.

If you find it more taxing than writing C or C++ it's probably either because you haven't internalised the rules of the borrow checker, or because your C or C++ are riddled with various kinds of serious issues.

replies(7): >>42161052 #>>42161225 #>>42161510 #>>42162166 #>>42162494 #>>42162555 #>>42162621 #
chipdart ◴[] No.42162621[source]
> I have memorised the UB rules for C.

Why? What's wrong with using one of the many static code analysis tool to tell you about them if/when they appear?

replies(1): >>42163225 #
1. rcxdude ◴[] No.42163225[source]
Those tools can't reliably identify undefined behaviour.
replies(1): >>42163678 #
2. chipdart ◴[] No.42163678[source]
> Those tools can't reliably identify undefined behaviour.

I'm sorry, can you explain what leads you to believe your hypothetical scenario is an argument rejecting the use of static code analysis tools?

I mean, I'm stating the fact that there are many many tools out there that can pick up these problems. This is a known fact. You're saying that hypothetically perhaps they might not catch each and every single hypothetical case. So what?

replies(1): >>42164203 #
3. rcxdude ◴[] No.42164203[source]
They're a good idea, but not a substitute for knowing the rules. And they don't just miss theoretical cases, they miss problems in practice even when used rigourously.
replies(1): >>42164441 #
4. chipdart ◴[] No.42164441{3}[source]
> They're a good idea, but not a substitute for knowing the rules.

It's a good thing no one made that claim, then.

The whole point is that were seeing people in this thread making all sort of wild claims on how it's virtually impossible to catch these errors in C++ even though back in reality there are a myriad of static analysis and memory checker tools that do just that.

Your average developer also knows how to type in a space character but still it's a good idea to onboard linters and automatic code formatters.

replies(2): >>42164644 #>>42165992 #
5. eddd-ddde ◴[] No.42164644{4}[source]
You made the claim

> Why? What's wrong with using one of the many static code analysis tool to tell you about them if/when they appear?

You clearly pose static analysers as an alternative to understanding UB. You still need to understand how things work.

6. rcxdude ◴[] No.42165992{4}[source]
It's not impossible to catch those errors in C and C++. In fact, every time you run a new tool against a large C or C++ codebase you will find new ones. What none of these tools do is catch all the issues, as demonstrated by the fact that people keep finding new ones.