RE:
In https://lists.llvm.org/pipermail/llvm-dev/2021-June/151199.html
C is moving towards a provenance model; you can find the details in
this committee TR that Joshua Cranmer linked:
[http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2676.pdf](http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2676.pdf)
Provenance is not part of the existing C standard. This proposal is by no means a settled issue. It would be interesting to hear what Clang/llvm developers think. Speaking for myself, I think the proposal has interesting ideas, but papers over a lot of difficult issues, lacks motivation, and potentially could have very negative effects on C semantics in its current state. I'd prefer to fix the C standard so that it is possible to write operating systems, malloc, and other important code in standard C before we consider adding such a far reaching change.
vy
Provenance/N2676 is that fix of the C standard. All current C/C++
specifications have wordings that are obviously motivated to make some
compiler optimizations possible, but when those are implemented leads
to miscompilation of programs that most agree should have worked. The
current situation of implementing an optimization and only later
finding out that it is bad when someone complains about it is
obviously unsatisfying. As a result, the only safe option is to treat
a pointer like an integer, but this would also prohibit many
optimizations that an optimizing compiler nowadays is expected to do.
I am curious, what are those negative effects on semantics that you
are referring to? How would you fix the C standard?
Michael
I don’t see how to write a memory allocator under N2676 (what is the provenance of a freed block of storage?)
—“Our semantics special-cases malloc and the related functions, by giving
their results fresh provenances. This is stylistically consistent with the ISO text, which also special-cases them,
but it would be better for C to support a general-purpose annotation, to let both stdlib implementations and other
libraries return pointers that are treated as having fresh provenance outside (but not inside) their abstraction
boundaries.”
So how does one write an allocator not called “malloc”? And how does the code inside the abstraction boundaries work since free(p) needs to transform
the type of the storage pointed to by “p” and presumably zero the provenance so it can consolidate storage blocks etc.?
or consider for device memory:
----“We leave the design of exactly what escape-hatch mechanisms are needed here as an open problem. For memory-
mapped devices, one could simply posit implementation-defined ranges of such memory which are guaranteed not
to alias C objects. The more general linkage case is more interesting, but well outside current ISO C. The tracking
of provenance through embedded assembly is similar.”
and
— "To be conservative w.r.t. current compiler behaviour, pointer equality in the
semantics should give false if the addresses are not equal, but nondeterministically ( either take provenance into ac-
count or not if the addresses are equal "
To me, all these things need to be decided first otherwise provenance makes things worse.
My intent is not to debate N2676 here, but to suggest it is not a done deal. Provenance is not in the standard now and not necessarily in the standard in the future and its not too late for people to weigh in.
My intent is not to debate N2676 here, but to suggest it is not a done deal. Provenance is not in the standard now and not necessarily in the standard in the future and its not too late for people to weigh in.
N2676 is the base draft for an unpublished Technical Specification, so
hopefully it's well understood that this is not in the standard and
that the whole point is for implementers and users to weigh in on the
choices in the document and provide feedback based on implementation
and usage experience *before* the standard is changed. However, the TS
does suggest a particular path forward and that's based on years of
discussion in WG14 on the various potential options, so there's a
clear signal as to which path WG14 *thinks* it will be taking based on
the feedback we've received thus far. I'm really glad to see the LLVM
community evaluating the pros and cons of that option for our
particular implementation as that will provide extremely valuable
concrete feedback to WG14.
~Aaron