Moving to a provenance-aware memory object model for C: proposal for C2x

https://hal.inria.fr/hal-02089889/

by matt_d • 7 years ago

68 50 7 years ago

hal.inria.fr

growtofill• 7 years ago

Wow, what a horribly designed website.

Here’s the direct link to the pdf: https://hal.inria.fr/hal-02089889/document

nestorD• 7 years ago

Its a HAL website, the french equivalent of arxiv. Most french research institute have one to publish openly.

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

msla• 7 years ago

It's still a horribly-designed website.

zik• 7 years ago

Can anyone summarise?

pm2152• 7 years ago

The "n2362+appendix" pdf is only 7 pages if you ignore the appendix which is "changes to the actual C standard to implement the proposal", so it's not that long to read, and it starts with a description of the basic idea. The short summary is that it's trying to formalize an existing idea (which has been discussed by the committee and used by compiler implementations but not really nailed down in the standards text) about when the compiler can assume two pointers don't alias. Intuitively, if you create a pointer by dubious arithmetic means (eg by adding 1 to the address of a local variable) the compiler shouldn't have to assume that that might alias with other local variables, or it would generate terrible code out of paranoia. But you do want common operations where a legitimate pointer is arithmetically manipulated to work. The paper proposes a formalization that accommodates reasonable things but rules some implausible/weird stuff as UB to accommodate both those desires.

simias3• 7 years ago

It's interesting work but I really wonder if it's desirable. What real-world problems is this supposed to solve exactly? Making the compiler extra-clever about detecting aliasing seems like a good recipe for having broken code appear to work correctly until it doesn't or getting strange behavior that's a pain to debug. Current aliasing rules are already a significant pain point in the C standard IMO, I personally don't want them to become even more complicated.

The only concrete example given in the paper (having two contiguous objects and referencing the 2nd one through a pointer on the first one) is frankly contrived and I'm not sure how that can be considered reasonable or good code. The only time I could see myself writing code like that is when dealing with memory-mapped hardware registers at fixed addresses which would let me do funky pointer arithmetic, but in this scenario the pointer is usually tagged as volatile and sometimes accompanied by a memory barrier to make sure the compiler does the right thing.

Note that if the programmers really wanted the code given in the paper to work correctly (i.e. changing y through an offset pointer from x) they could do it by adding a memory barrier such as

    asm volatile("": : :"memory");

after the *p = 11;. Is it elegant? Arguably not, but it seems like such a niche use to me that it seems like a fair compromise. It's also not standard C but if you're making such pointer gymnastics chances are you're already making assumptions about your environment that go beyond the standard.

I much prefer Rust's approach of "mutable references never alias" and if the programmer really needs to share a reference they have to manually do the work by wrapping. Of course integrating that into C in a backward-compatible fashion doesn't seem very practical.

voldacar• 7 years ago

Isn't this exactly what __restrict is for though?

layoutIfNeeded• 7 years ago

Sorry for my ignorance, but my impression was that in the native spaces the consesus is that Rust is the only reasonable choice for any new code. So I don’t understand why people are still working on a C2x standard - shouldn’t the native community work on a roadmap to migrate the existing legacy C/C++ codebases to Rust instead? Am I missing something here?

jfk13• 7 years ago

Perhaps the "migrate the existing legacy C/C++ codebases to Rust" problem is a lot bigger than you're imagining?

0815test2• 7 years ago

We're all just waiting for a formal Rust Reference Manual to be published, so that the official ANSI/ISO C and C++ standards can be replaced by a single-line reference to that. Since all practical C/C++ programs will necessarily invoke undefined behavior at some point, doing this is even 100% legal by the previous versions of these standards, even though it means rejecting the older C/C++ syntax altogether; it's really just replacing runtime nasal demons with a far more benign compile-time diagnostic!

WoodenChair• 7 years ago

Sorry for my ignorance, but my impression was that in the native spaces the consesus is that Rust is the only reasonable choice for any new code.

Please tell that to the many millions of C/C++ programmers writing new code every day, who are only vaguely familiar with Rust if at all. If by consensus you mean "consensus amongst the vanguard of Hacker News" then yes. If you mean "consensus" as in the "consensus of the software development industry" then absolutely not.

adamnemecek• 7 years ago

If you program but don’t post about it on HN, are you really programming?

v_lisivka• 7 years ago

Please tell that to the many millions of C/C++ programmers writing new code every day, who are only vaguely familiar with Rust if at all.

Just call it "C20", and they will learn it in a week.

CJefferson• 7 years ago

I love Rust, but there are so many places it isn't feasible (yet). Most microcontroller don't support it for a start.

Ericson2314• 7 years ago

Eh is think you can make it for anywhere you can use C and clang. Manufacturers write such shit code anywway I don't midnight not using their boilerplate at all.

detaro• 7 years ago

Such a consensus does in no way exist (even if you assume that there's a consensus on "we need to replace C and C++", which there also isn't, Rust isn't the only "better" native language), and "all new code must be Rust" is mostly a meme by overly enthusiastic enthusiasts. Rust is a tiny sliver of native code written today, not to speak of the orders of magnitude bigger collection of existing code bases and tooling existing outside of it.

raphlinus• 7 years ago

In addition, it is entirely possible that when Rust has a formal semantics, it will use exactly such a provenance-aware memory object model to describe which pointer operations are safe and which lead to UB. People using the safe fragment of Rust won't care about this, but that's certainly not all of Rust.

pjmlp4• 7 years ago

Rust is very nice as safe systems programming language.

But every sane safety advocate also acknowledges that we aren't going to throw away the millions of lines written in C and C++ tomorrow, and there needs to be a way to keep UNIX derived platforms, while improving their security.

vvanders2• 7 years ago

That's why Rust's FFI story of being the C ABI is wonderful. I've used tons of c libraries but still get to take advantage of Rust's advantages in all the new code I write.

jandrewrogers3• 7 years ago

You are missing that Rust still can't do many things as well, or as efficiently, or at all as e.g. C++17. It is not suitable for many domains of systems programming. Some safe, simple, idiomatic C++ code is difficult or impossible to express in Rust. Some important safety features in modern C++ don't exist in Rust, so you'd need to remove them from the code base or rewrite the code using a less safe design.

There is room for a new systems programming language but the current solution to the above issues is to make the code "unsafe", slower, and/or more bloated, which offsets its nominal benefits. For many C++ software architectures, memory safety is a non-issue in practice, so that isn't always a compelling feature. The benefits of Rust versus C++ are significantly overstated by its fans, and its current limitations tend to be overlooked. (I can't speak for C, it has been too long since I worked with it at scale.)

c-cube2• 7 years ago

What safety feature does rust lack exactly? I know C++ has some more expressive features (like templates on values), but safety? C++ is as unsafe as it gets…

a1369209993• 7 years ago

Some safe, simple, idiomatic C++ code is difficult or impossible to express in Rust.

[citation needed]?

I could definitely believe there are such things, but all the examples I've encountered are things like doubly-linked lists where the complainer flatly ignores the existence of the 'unsafe' keyword.

Moving to a provenance-aware memory object model for C: proposal for C2x

Related Stories