8 ms·

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

68 points by matt_d 8y ago

growtofill 8y ago
Wow, what a horribly designed website. Here’s the direct link to the pdf: https://hal.inria.fr/hal-02089889/document https://hal.inria.fr/hal-02089889/document
- nestorD 8y 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 https://en.wikipedia.org/wiki/Hyper_Articles_en_Ligne
  - msla 8y ago
    It's still a horribly-designed website.
zik 8y ago
Can anyone summarise?
- pm215 8y 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.
  - simias 8y 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.
    - fooker 8y ago
      >I much prefer Rust's approach of "mutable references never alias" This rules out a vast majority of fundamental algorithms. Jumping through hoops for getting simple logic working doesn't sound very desirable.
      - simias 8y ago
        There's always unsafe. With generics you can always implement these fundamental algorithms once and for all in an unsafe block and then reuse that. No need to reimplement quicksort for every data type. But I'm not proposing to bring that to C (although it seems that generics are slowly creeping in by way of the macro system), I'm just saying that I think the changes proposed in this paper would make the language more complex without really making it easier to write C code 99% of the time.
layoutIfNeeded 8y 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 8y ago
  Perhaps the "migrate the existing legacy C/C++ codebases to Rust" problem is a lot bigger than you're imagining?
- 0815test 8y 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 8y 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 8y ago
    If you program but don’t post about it on HN, are you really programming?
    - 8y ago
fithisux 8y ago
late april 1st?

68 points by matt_d 8y ago

Wow, what a horribly designed website. Here’s the direct link to the pdf: https://hal.inria.fr/hal-02089889/document https://hal.inria.fr/hal-02089889/document

nestorD 8y 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 https://en.wikipedia.org/wiki/Hyper_Articles_en_Ligne
- msla 8y ago
  It's still a horribly-designed website.

zik 8y ago

Can anyone summarise?

pm215 8y 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.
- simias 8y 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.
  - fooker 8y ago
    >I much prefer Rust's approach of "mutable references never alias" This rules out a vast majority of fundamental algorithms. Jumping through hoops for getting simple logic working doesn't sound very desirable.
    - simias 8y ago
      There's always unsafe. With generics you can always implement these fundamental algorithms once and for all in an unsafe block and then reuse that. No need to reimplement quicksort for every data type. But I'm not proposing to bring that to C (although it seems that generics are slowly creeping in by way of the macro system), I'm just saying that I think the changes proposed in this paper would make the language more complex without really making it easier to write C code 99% of the time.

layoutIfNeeded 8y 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 8y ago
Perhaps the "migrate the existing legacy C/C++ codebases to Rust" problem is a lot bigger than you're imagining?
0815test 8y 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 8y 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 8y ago
  If you program but don’t post about it on HN, are you really programming?
  - 8y ago

fithisux 8y ago

late april 1st?