<div dir="ltr">I don't see how to write a memory allocator under N2676 (what is the provenance of a freed block of storage?)  <div>---"Our semantics special-cases malloc and the related functions, by giving<br>their results fresh provenances. This is stylistically consistent with the ISO text, which also special-cases them,<br>but it would be better for C to support a general-purpose annotation, to let both stdlib implementations and other<br>libraries return pointers that are treated as having fresh provenance outside (but not inside) their abstraction<br>boundaries."</div><div><br></div><div>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</div><div>the type of the storage pointed to by "p" and presumably zero the provenance so it can consolidate storage blocks etc.?<div><br></div><div> or consider for device memory:<br>----"We leave the design of exactly what escape-hatch mechanisms are needed here as an open problem. For memory-<br>mapped devices, one could simply posit implementation-defined ranges of such memory which are guaranteed not<br>to alias C objects. The more general linkage case is more interesting, but well outside current ISO C. The tracking<br>of provenance through embedded assembly is similar."<br><br>and<br><br>--- "To be conservative w.r.t. current compiler behaviour, pointer equality in the<br>semantics should give false if the addresses are not equal, but nondeterministically ( either take provenance into ac-<br> count or not if the addresses are equal "<div><br></div><div>To me, all these things need to be decided first otherwise provenance makes things worse.</div><div><br></div><div>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.</div><div><br></div><div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 17, 2021 at 1:57 AM Michael Kruse <<a href="mailto:llvmdev@meinersbur.de" target="_blank">llvmdev@meinersbur.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Am Mi., 16. Juni 2021 um 19:32 Uhr schrieb Victor Yodaiken via<br>
llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>:<br>
>  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.<br>
<br>
Provenance/N2676 is that fix of the C standard. All current C/C++<br>
specifications have wordings that are obviously motivated to make some<br>
compiler optimizations possible, but when those are implemented leads<br>
to miscompilation of programs that most agree should have worked. The<br>
current situation of implementing an optimization and only later<br>
finding out that it is bad when someone complains about it is<br>
obviously unsatisfying. As a result, the only safe option is to treat<br>
a pointer like an integer, but this would also prohibit many<br>
optimizations that an optimizing compiler nowadays is expected to do.<br>
<br>
I am curious, what are those negative effects on semantics that you<br>
are referring to? How would you fix the C standard?<br>
<br>
Michael<br>
</blockquote></div>