> continuing the discussion from last year at EuroLLVM, the GNU Tools Cauldron,
> and elsewhere, we (the WG14 C memory object model study group) now
> have a detailed proposal for pointer provenance semantics, refining
> the "provenance not via integers (PNVI)" model presented there.
> This will be discussed at the ISO WG14 C standards committee at the
> end of April, and comments from the community before then would
> be very welcome. The proposal reconciles the needs of existing code
> and the behaviour of existing compilers as well as we can, but it doesn't
> exactly match any of the latter, so we'd especially like to know whether
> it would be feasible to implement - our hope is that it would only require
> minor changes.

Firstly thank you for the enormous amount of work that you have done on
this topic. I am currently at the ACCU conference. Myself, Guy, Herb and
Michael Wong are hoping to arrange a meeting whilst here to discuss your
proposals such that I can take an informed opinion to the WG14 meeting
end of this month.

On the papers themselves, for me personally, I found them a bit too
language-theory-centric. I think everybody gets that aliasing
inconsistency ought to get standardised, however I notice a visceral
reaction amongst attendees here to the notion that this part of the
language is going to get fiddled with. In other words, I think that this
part of the language gives people a lot of fear and doubt, and that
emotional reaction may impede the progress of these reforms at WG21
which is, after all, many times larger than WG14, and thus far harder to
achieve consensus at.

Personally speaking, I find that what programmers particularly hate is
the ground shifting beneath them without realising it. They especially
hate code which worked, and then subtly stops working in non-obvious
ways on later CPUs and toolchains. They would FAR prefer if a newer
compiler refused to compile code which might not behave as it did on an
earlier compiler, even if that meant increased upgrade costs.

To that end, if your papers spoke more about how compilers might refuse
to compile problem pieces of code found in the real world, with example
potential diagnostic messages, rather than reduced examples showing UB
vs DB, I think that would help "sell" the value vs fear in these proposals.

I also do think that you need to talk more about how these proposals can
be properly applied to C++. C++ objects may have discontiguous storage,
and without substantial changes to the C++ abstract machine, I don't see
how your provenance proposals can be applied to such kinds of object.
That suggests that either the C++ abstract machine must be changed, or
your provenance proposals, and probably most likely a bit of both.

I appreciate that this is much more a recommendation for WG21 than for
WG14. However I also think there is a huge groundswell of latent
goodwill and support for your proposals. It just needs to be pitched
right to rally the troops to the cause.

Niall