Hi Niall,

thanks for the comments.

On Tue, 9 Apr 2019 at 12:41, Niall Douglas <s_sourceforge_at_[hidden]> wrote:
>
> > 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,

That's probably perfectly rational on their part, unfortunately. But it's worth
emphasising that as far as possible we are trying to clarify what the
language is now, for these things that have never been nailed down in
the ISO text, rather than to *change* the language.

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

We agree that that is and should be a big concern.

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

There certainly might be scope for better diagnostics, but a lot of what's
going on is nailing down what compilers can legitimately assume
about aliasing when they *can't* figure out everything that's going on,
and in those cases it's hard to see what could be done.

> 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 might be missing too much C++ abstract machine context to understand
that - naively, I'd expect it to be possible to tag all the relevant storage
with a provenance (perhaps with slightly different metadata) in the abstract
machine.

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

thanks,
Peter


> Niall