[Info-vax] Rust as a HS language, was: Re: Quiet?

[Dan Cross]

In article <jb3mlhF98vlU1 at mid.individual.net>,
Bill Gunshannon  <bill.gunshannon at gmail.com> wrote:
>On 4/5/22 15:59, Dan Cross wrote:
>> [snip]
>> The point is that, even though C has a standard, it is riddled
>> with almost inescapable UB, and compiler writers can, and WILL,
>> take advantage of that over time.  New versions of compilers may
>> well introduce UB-based optimizations that fundamentally alter
>> the behavior and indeed the correctness of programs without the
>> programs themselves changing.
>
>But, that was my point exactly.  A definition of "UB" means that
>particular case should never be used because the results are "UB".
>Not the fault of the language.  Not the fault of the compiler.
>Strictly the fault of truly bad programmers.

Ah, so you think it's EASY to avoid UB in C.  That's what a lot
of folks say, but it turns out that it's nearly impossible to do
so in a non-trivial codebase.  That's because often the UB isn't
_in the source program_ but is emergent only after multiple
layers of translation and optimization have kicked in.

I used to sit down the hall from a bunch of folks who work on
LLVM and its C/C++ compilers; I once asked them, "why can't you
just give me a compiler flag that will error out on UB?"
They pointed me to things like this:

https://blog.regehr.org/archives/213

>> There is _tons_ of this floating around with respect to the
>> memory model, which wasn't even specified until C11, even though
>> we've been writing multithreaded C programs since the 70s (e.g.
>> the Unix kernel).
>> 
>> And UB is extraordinarily easy to trip over in C.  For example,
>> consider this almost trivial function:
>> 
>> uint16_t
>> mul(uint16_t a, uint16_t b)
>> {
>> 	return a * b;
>> }
>
>OK, I have to ask.  "UB" means "undefined Behaviour", right?
>Just so I know we are talking about the same thing here.

Yes, but I don't think we're talking about the same thing.

This may be interesting to you:
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html

>Exactly.  A good programmer would have done it correctly and not
>written it relying on UB.  That's my point.

You're conflating correctness with undefined behavior, when the
two are not equivalent.  Most "good" programmers wouldn't even
know that it was UB, and not all UB is bad.  If we tested _every
possible situation_ in C for UB, we'd have unwieldy programs.

>> In Rust, we'd write it as:
>> 
>> fn mul(a: u16, b: u16) -> u16 {
>>      a.wrapping_mul(b)
>> }
>> 
>> In Rust, by default, _any_ overflow can panic the program, but
>> we can explicitly request modular arithmetic via `wrapping_mul`.
>
>Well, I don't know Rust so I really have no idea what that means.

As I said before to Simon, I highly encourage you to have a go
at poking at it a bit.

>But, once again, it looks like we are trying to create languages
>who's intent is to stop programmers from shooting themselves in
>the foot.

Yes.  I also have a guard on my chainsaw, even though I know how
to use it properly.

>A better idea would be teaching the programmer not to
>shoot himself in the foot because if you rely on a language to do
>it programmers will continue to shoot themselves in the foot.

Sadly, 65 years of industry history has shown that to be pure
fantasy.  Simply put, our best and brightest programmers write
buggy programs.  Many of them wrote those buggy programs decades
ago.

After a few painful experiences, the very best of those develop
and adopt tools that allow them to do so more safely.

As I mentioned, concurrency is going to be a big source of this
sort of UB-driven "bug" in the coming years.  Given that e.g.,
C didn't have a standard memory model when the 1988 ANSI
standard was written, associated UB wasn't even a thing then.
Claiming that someone who wrote multithreaded code in ANSI C in
the 90s that exhibits UB with respect to the most recent
standards is a "truly bad programmer" is disingenuious at best.

	- Dan C.