Hacker News Reader

Comment by antirez | Hacker News Reader

Actually I look forward for enough momentum to be created in the community, to allow new C standards to change the way undefined behaviors are conceived, and make them as specified as possible, and even when they cannot in reasonable unique ways, to provide reference possible behaviors to select in order to have the least unexpected outcome for the programmer. Especially now that low level programming is abstracting away, exactly but not only because of Rust itself, we need a C that is more C than what it became in recent years. After all we don't really need to change the language, but just the new specifications and the compilers implementations of UB.

View on HN

It would also be nice if Rust had a specification. Without a spec it's impossible to build a correct alternative Rust implementation.

We're still working on it. In the meantime, there is at least one alternative implementation. It doesn't implement the borrow checker, but can successfully bootstrap a bit-identical rustc. https://github.com/thepowersgang/mrustc

Just pains me that the Rust team is so oblivious to the fact that they need a spec if they ever hope to have a chance to replace C.

We are not oblivious. First of all, we are not really trying "to replace C." Second, a tremendous amount of work has been put into specifying Rust. It's just also a tremendous amount of work. Like, "the EU has given grants of millions of Euro towards working on it but we're still not done" amounts of effort.

C did not have a standard for 18 years, it was first created in 1972, and ANSI C didn't appear until the spring of 1990. I'm not suggesting that it took them 18 years to write a spec, it's that it wasn't really needed for a long time. Expecting Rust to have one after five years is aggressive. Some languages have done this! I think we'll end up somewhere between what C did and what C# did, in this regard.

Go has a spec, which has been used to make gccgo. I'm not very familiar with other specs: is it fair to say that the Go spec is less detailed and so was able to be completed before 1.0? Is it "not a real spec" compared to ANSI C, ECMA, etc.?

I have not read the Go spec, and so I can't really comment.

However, you do also bring up something that's a good point when it comes to this discussion: a lot of people treat "a spec" as a binary thing: a language has it, or does not have it. But specs are written by humans, and have their own mistakes, bugs, errata, etc.

One of the reasons that we haven't wanted to declare "this is the spec for Rust" is that we want to have a good, possibly even formally verifiable spec. The reference is basically at a fairly reasonable informal spec level.

And yet C, which had no spec at the time, beat out Algol, which had one.

You had to pay for Algol compilers, while C came for free with UNIX tapes that landed on university labs out of Bell Labs.

That's not true, as mrustc proves. The C and C++ specs are incredibly ambiguous and frankly I don't know if they add that much value over good documentation.

When it comes to high-level stuff especially in C++, like the exact rules for template deduction, I think the specs are reasonably clear and do add value. But for the low-level memory model and undefined behavior, the specs are indeed extremely ambiguous. In fact, they're often outright 'wrong', in the sense that they have too little undefined behavior to support common compiler optimizations (e.g. [1] [2])... while making other things undefined for no benefit [3].

[1] https://fzn.fr/readings/c11comp.pdf

[2] https://www.cs.utah.edu/~regehr/oopsla18.pdf

[3] https://www.imperialviolet.org/2016/06/26/nonnull.html

You are never going to get any guaranteed sensible behaviour for a double free or an use after free [1]. In comparison to those giant issues, all other instances of UB are minor.

[1] well, you can today by swapping malloc for a GC-enabled implementation, but the fact is that almost nobody does.

Surely signed integer overflow is also a big problem. And reads from uninitialized memory.

I don't think integer overflow itself is a big deal. Unbounded array access, especially local array acces, is though, and I forgot about it.

> well, you can today by swapping malloc for a GC-enabled implementation

You don't need GC for this (at least, in the sense of "we'll call free for you"), you just need to verify that things passed to free were handed out via malloc.

> allow new C standards to change the way undefined behaviors are conceived,

Of all the potential issues that might be attributed to C, undefined behavior (UB) is the one that creates few to no problems at all.

To me, complaining about UB is like complaining about the quality of a highway once they intentionally break through the guard rails and start racing through the middle of the woods.

The reason why some behavior is intentionally left undefined is to enable implementations to do whatever they find best in a given platform. This is not a problem, it's a solution to whole classes of problems.

https://en.wikipedia.org/wiki/Undefined_behavior

This is like saying there's nothing dangerous about guns, because it takes a human to make them dangerous.

C is not unsafe if you only write safe code. But humans are fallible, and "just don't write unsafe code" is not a solution.

> This is like saying there's nothing dangerous about guns, because it takes a human to make them dangerous.

If you want to go with that analogy, UB is a kin of you intentionally pointing your gun to your foot, taking your time to aim it precisely on your foot, and in spite of all the possible warnings and error messages that are shouted at you... You still decide that yes, what you want to do is to shoot yourself in the foot because that is exactly what you want to achieve.

And then complain about the consequences.

> If you want to go with that analogy, UB is a kin of you intentionally pointing your gun to your foot, taking your time to aim it precisely on your foot, and in spite of all the possible warnings and error messages that are shouted at you…

Yeaaaah not really:

    #include <stdio.h>
    #include <stdlib.h>
    #include <string.h>

    static char a[128];
    static char b[128];

    int main(int argc, char *argv[]) {
      (void)argc;
      strcpy(a + atoi(argv[1]), "owned.");
      printf("%s\n", b);
      return 0;
    }

compiles with no warning using clang (8), even with -Weverything

And that’s a super easy case, it’s not a use after a dynamic callback somewhere freed a pointer it did not own, or a function 5 levels deep (or worse in a dll) didn’t check its input pointer which only became occasionally null years later.

And many (myself included) think that the compiler should not warn about this code, even if it can potentially exhibit undefined behavior, because it would make it impossible to write code at all without warnings. (A good static analyzer or code reviewer should call it out, though.)

That's completely fair. I'm not criticising the compiler not complaining about this code, I'm providing a counter-point to rumanator's assertion that:

> UB is a kin of you intentionally pointing your gun to your foot, taking your time to aim it precisely on your foot, and in spite of all the possible warnings and error messages that are shouted at you…

Because they could hardly be more wrong, the average UB is completely invisible to static analysers because it's a dynamic condition which the type system is not smart enough to move to static. That's why it's an UB and not, say, a compile error.

OpenBSD has almost a singular focus on security, and even they have vulnerabilities. If they can't write safe C 100% of the time, what hope does anyone else have?

So... Is there an OS with zero vulnerabilities written in Rust/Go/Ada/anything that I should know about? If nobody's written safe Rust/Go/Ada/whatever 100% of the time, what hope do I have?

Now, I think that particular argument is poor. The more defensible version would be to look at the proportion of errors that occurred in C that would not occur in your language of choice, versus the number of errors that occur in this other language that would be unlikely to occur in C. And for completeness it would be good to do some sort of evaluation as to whether they were other gotchas like performance of the resulting code and programmer productivity. I expect that in the grand scheme of things, C is not the best option, but 100% perfection is an absurd goal post and makes it a lot easier for people to dismiss your argument.

Redox[0] actively wants to hear your vulnerability reports.

[0]: https://www.redox-os.org/

What hardware does it run on?

I looked through the documentation and cannot find what hardware it runs on and how to set it up. The Getting Started for real hardware returns a 404 page: https://doc.redox-os.org/book/real_hardware.html

Yes, Unisys ClearPath MCP, written in NEWP, a secure systems language 10 years older than C.

It is still in use, because when governments want safety above anything else, they buy such OSes, not UNIX clones.

https://www.unisys.com/offerings/clearpath-forward/clearpath...

Implementation defined behaviour is not the same as undefined behavior.

And unspecified behaviour is (slightly) different again.

While this is the ideal theory I think we've all seen how it simply doesn't pan out in practice.

The numerous and regular terrifying security bugs that are being found in ancient tools (some 30+ years old) are a living testament that the philosophy you quoted just doesn't translate that well into the reality of humans programming the current breed of computers.

Hence the existence of languages like Rust and the recent general strive towards more correctness and more compile-time catching of potential problems (especially in light of GCC 10's new `-fanalyzer` flag).

All the other low level stuff of C can be handled by a professional programmer in different ways, using tools like Valgrind, with careful coding, but especially with higher order libraries, so you don't have to write much low level code. Any language is dangerous and bug prone if the standard library has no dynamic strings and basic data structures. If you have the right tools, C becomes a lot more high level, a lot more safe, and has a long story of solving very important problems reliably and in a portable way.

Yeah I agree.

But even more than that, I think a lot of people would like to overlook that programming is fundamentally unsafe. Even if you're working in a safe language, that language's runtime is almost certainly in an unsafe language, making syscalls through a library written in an unsafe language, interacting with an OS written in an unsafe language, interacting with hardware running on firmware written in an unsafe language.

Sure there should be a boundary somewhere. But whether that boundary should be a type system or valgrind/cppcheck/etc. differs case-by-case.

Your wording only works for "implementation defined", not "undefined". Both exist in the standard, and the former is quite sane to use. E.g., on any normal architecture, specifying signed integer overflow to be implementation defined would have been great, though on e.g. the JS-style machine that abuses IEEE floats in limited range as integers, addition get's weird once the point floats to the left of where you'd normally write it by hand (in non-scientific notation).

  y = x;
  x += 1;
  x -= 1;
  true == (x != y);

But I don't know of any actual integer machine that would want integer overflow to actually be UB.

"like complaining about the quality of a highway once they intentionally break through the guard rails"

Your metaphor brings to mind an image of someone who can see the guard rail, and then deliberately chooses to expend quite non-trivial effort to break them. This is not an accurate metaphor.

As I'm not in the metaphor fix-up business, because I believe they tend to mess us up in precisely this sort of way, let me simply directly point out this gets it backwards. The default is that you will write a program shot through with undefined behavior, and you must make quite substantial, intellectually-challenging efforts above and beyond the intellectual challenge of writing something in C at all that at least sometimes works, to write your program in a way that doesn't have UB in it. It has no resemblance to driving down a road in a normal fashion and then bashing guard rails down.

What happens when you reach outside of an array or access memory after it was freed falls under UB and those are the most serious problems about the C family of languages.

> To me, complaining about UB is like complaining about the quality of a highway once they intentionally break through the guard rails and start racing through the middle of the woods.

Sure, if those guardrails are 1mm tall and so barely visible, then that's a valid analogy to C. I hope you can see why this is not an ergonomic design that will lead to safe programs (or safe highways).

WG 14 doesn't seem that interested in improving C's security story.

Right now I see more efforts coming out Microsoft and static analysis tool vendors than any WG 14 mailing.

Last I checked UB was undefined by the standard, but compilers still need to define their behavior on each architecture.

Dictating that all architectures implement UB the same way would have significant overhead, since it would force programs that don’t rely on UB to run in emulation on all but one architecture (at best).

that's implementation defined

Undefined behavior does not need to be consistent, either across different programs, or within the same program. It does not need to be consistent within different times that the program is run, and it does not need to be documented anywhere. It does not need to be sensible, does not need to be predictable, and does not need to give any diagnostics to warn the programmer. Undefined behavior means that you have passed outside of the realm governed by the standard, and that HERE BE DRAGONS.

Implementation-defined behavior works as you say, where each compiler can define how it responds to certain circumstances.

Reply on news.ycombinator.com