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

David Brown <david.brown@hesbynett.no> wrote:

On 09/07/2025 04:39, BGB wrote:

On 7/2/2025 8:10 AM, Kaz Kylheku wrote:

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

>

...
 

>
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.
>

 
You might not be aware of it, but the author Jens Gustedt is a member of
the C standards committee, and has been for some time.  He is the most
vocal, public and active member.  I think that suggests he has quite a
good understanding of C and the ISO standards!  Not everyone agrees
about his ideas and suggestions about how to move C forward - but that's
fine (and it's fine by Jens, from what I have read).  That's why there
is a standards committee, with voting, rather than a BDFL.
 

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

 
There have been plenty of papers and blogs written about pointer
provenance (several by Gustedt) and how it could work.  It's not a very
easy thing to follow in any format.  A patch to current C standards is
perhaps the least easy to follow, but it is important for how the
concept could be added to C.

I looked at the blog post.  About two thirds of it is explaing what
I consider obvious.  Later he makes some assumptions/rules and
claims that they cover segmented model.  But assumption:

:  Two pointer values are equal if they correspond to the same             
:  abstract address.

is problematic for 8086 segmentation (would force "huge" style
pointer comparison).  It is probably unworkage for more abstract
segmentation (like in 286) when there are overlapping segments

He spends time talking about XOR trick, but leaves different
(and IMO much more important trick in undefined teritory).
Namely, modern ARM and RISC-V embedded processors are 32-bit,
so need 32-bit pointers.  But low end processor frequently
have tiny RAM that could be addressed using 16 bits.  More
precisely, one can use base pointer initialized to address
of start of RAM and access memory location using 16 bit offset
from the start of RAM.  AFAICS definitions in the blog post
put this strictly into undefined territory, but I expect this
to work as indended in gcc.

Later he writes about exposure and synthetised pointers.
That is rather natural, but I did not found explicit
statement how exposure and synthetised pointers are
related to aliasing.  Maybe the intent is like:
"access via synthetised pointer may alias access to
any exposed storage instance".  OTOH in cases like
convertion to offset with respect to some base and
back we deal with synthetised pointers, but in principle
compier could track bases and offsets and came with
quite good alias analysis.

More generally, the blog post looks like very preliminary
analysis that compiler should do before further work on
alias analysis.  But compiler writer presumably knows
the targert, so can make assumption that better fit
actial situation than assumptions made in the blog post.

So, ATM it is not clear to me that puting such things in the
standard adds value.  It could if standard formulated new
aliasing rules, but I see no new aliasing rule in the blog
post.  And IMO new rules should be related to algorithms:
without good algorithms rules must be either conservative
(disallowing optimizations) or risk breaking code.

--
                              Waldek Hebisch