Re: "The provenance memory model for C", by Jens Gustedt

On 2025-07-02, Alexis <flexibeast@gmail.com> wrote:

>
"This work has finally resulted in the publication of an international
standard, Technical Specification ISO/IEC TS 6010 (edited by Henry
Kleynhans, Bloomberg, UK) ...

OMG, it's a completely idiotic document. What it is is a kind of patch
against a specific version of ISO C, written in plain language rather
than in diff format. Like "replace this paragraph with this one, add
this sentence after that one, ...".

What the actual fuck? How will that be maintainable going forward, first
of all.

You can't follow what this is without applying the patch: obtaining
the exact ISO C standard that it targets and performing the edits.

Almost nobody is going to do that.

Right off the bat I spotted pointless shit in it that has nothing to do
with provenance:

  6.4.5 Equality operators

  1 In section 6.5.9 Equality operators, add the following after the rst
    sentence of paragraph 3:

  2 None of the operands shall be an invalid pointer value.

I don't have confidence in an author's understanding of C, if they
believe that ISO C defines the behavior of invalid pointers being
compared, such that this needs to be rectified by a private "patch"
of the text.

The concept of pointer provenance can be expressed other than
as a textual patch against ISO C.

It can be regarded as a language extension and documented similarly
to how a sane compiler documentor would do it.

"In this article, I will try to explain what this is all about, namely
on how a provenance model for pointers interferes with alias analysis of
modern compilers.

Well, no shit; provenance is often dynamic; whereas aliasing analysis
wants to be static.

For those that are not fluent with the terminology or
the concept we have a short intro what pointer aliasing is all about, a
review of existing tools to help the compiler and inherent difficulties
and then the proposed model itself. At the end there is a brief takeaway
that explains how to generally avoid complications and loss of
optimization opportunities that could result from mis-guided aliasing
analysis."

If you think that certain code could go faster because certain suspected
aliasing isn't actually taking place, then since C99 you were able to
spin the roulette wheel and use "restrict".

So the aliasing analysis and its missed opportunities are the
programmer's responsibility.

It's always better for the machine to miss opportunities than to miss
compile. :)

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca