4 ms·

I think you are confused about who is advocating what here. Pointer provenance is a real thing that has already happened and that compiler developers want. Sewe

by samth 3y ago

I think you are confused about who is advocating what here. Pointer provenance is a real thing that has already happened and that compiler developers want. Sewell's group has been working (eg in this thesis) to put that idea on a consistent foundation, and figure out how to make it compatible with the programs you care about.

JonChesterfield 3y ago
Some compiler developers want the provenance model as it allows cheaper alias analysis. Others don't as it breaks things like mmap of prebuilt hashtables. Application level C++ developers want it too, as it makes things slightly faster without breaking anything that would get past code review. My point of contention is with applying this to C. The main remaining uses are things like linux which can't be compiled as ISO C any more, instead requiring a bunch of compiler flags to opt out of things very like the provenance model. I claim there are zero use cases for C with "strict aliasing" rules and the like, and adopting the application facing copy-ideas-from-C++ approach will/has killed the language. GNU C will persist for a while, ISO C serves noone well.
- nine_k 3y ago
  Could you please give a simple practical example where pointer provenance or another similar anti-aliasing mechanism prevent a useful hardware-facing piece of code from being compiled?
- amluto 3y ago
  > Others don't as it breaks things like mmap of prebuilt hashtables. Can you elaborate? An mmap of prebuilt hash tables doesn’t work well in practice of the mmapped area contains pointers regardless of provenance, and an mmap of a hashtable that uses integer offsets doesn’t involve pointers. The only real issue I see is if the mmap contains objects but isn’t itself laid out like an object in the language in question, and you need to generate a pointer to one of those objects. (So mmapping an array of structs that don’t contain pointers is fine, but mmapping a mess that contains integer offsets referencing various things in the mmap that don’t nicely line up like an array is harder.) But I imagine that a pointer provenance system could have an operation that takes as input an mmap, an offset and a type and returns a pointer to the object with the type in question at the offset in question. It would check that the type makes sense (no pointers!) and could, if needed for the degree of safety require, also check for invalid aliasing.

by samth 3y ago

JonChesterfield 3y ago

Some compiler developers want the provenance model as it allows cheaper alias analysis. Others don't as it breaks things like mmap of prebuilt hashtables. Application level C++ developers want it too, as it makes things slightly faster without breaking anything that would get past code review. My point of contention is with applying this to C. The main remaining uses are things like linux which can't be compiled as ISO C any more, instead requiring a bunch of compiler flags to opt out of things very like the provenance model. I claim there are zero use cases for C with "strict aliasing" rules and the like, and adopting the application facing copy-ideas-from-C++ approach will/has killed the language. GNU C will persist for a while, ISO C serves noone well.

nine_k 3y ago
Could you please give a simple practical example where pointer provenance or another similar anti-aliasing mechanism prevent a useful hardware-facing piece of code from being compiled?
amluto 3y ago
> Others don't as it breaks things like mmap of prebuilt hashtables. Can you elaborate? An mmap of prebuilt hash tables doesn’t work well in practice of the mmapped area contains pointers regardless of provenance, and an mmap of a hashtable that uses integer offsets doesn’t involve pointers. The only real issue I see is if the mmap contains objects but isn’t itself laid out like an object in the language in question, and you need to generate a pointer to one of those objects. (So mmapping an array of structs that don’t contain pointers is fine, but mmapping a mess that contains integer offsets referencing various things in the mmap that don’t nicely line up like an array is harder.) But I imagine that a pointer provenance system could have an operation that takes as input an mmap, an offset and a type and returns a pointer to the object with the type in question at the offset in question. It would check that the type makes sense (no pointers!) and could, if needed for the degree of safety require, also check for invalid aliasing.