From owner-sc22wg14+sc22wg14-domo2=www.open-std.org@open-std.org Wed Apr 11 10:22:32 2018 Return-Path: X-Original-To: sc22wg14-domo2 Delivered-To: sc22wg14-domo2@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id F1FC9358A54; Wed, 11 Apr 2018 10:22:31 +0200 (CEST) Delivered-To: sc22wg14@open-std.org Received: from mail-qt0-f171.google.com (mail-qt0-f171.google.com [209.85.216.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by www.open-std.org (Postfix) with ESMTP id ECDD5356D4C for ; Wed, 11 Apr 2018 10:22:30 +0200 (CEST) Received: by mail-qt0-f171.google.com with SMTP id j17so1014766qtp.1 for ; Wed, 11 Apr 2018 01:22:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:reply-to:sender:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qpzfwwmhQGMQoNKEH0YXI1xOu2w3E1YWJRsG5qoxCnU=; b=JIZyyzadxTbvMxbKkV126uMWYie3725QNZOGNXfwZ+CR3Df4+EF5/jmfI66J57YjXy 60TA3dteozTUIbNiXSbxjWoG1+SgiFzbzCqxMhe7SyqmUFuh/c171tQgYVbcQulMEZL1 6ock74LAuN9tOsstsvriUODNovfAgNygxi+da69lUsn2QHHh5fBP45U+R9MOhfD4EdG9 ap0gYAU4gKXVPvS8Edxca9GmU51iFicX8RynU5PNR0UYdCI6XC4nmjJCC0xFP4UQyrws EXKJIq2djLIjHAEWf67EDnHH2zNFwvH5Xb7ABo3IGD/rPMJyk9miBpHBP1lz07cGSsOT Md8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:sender:in-reply-to :references:from:date:message-id:subject:to:cc; bh=qpzfwwmhQGMQoNKEH0YXI1xOu2w3E1YWJRsG5qoxCnU=; b=mQIDtB6dVu3R6CT+QSE+iomRl9PFzspFs5OXU6jkMQZ15SHumP1F7ZeeHoVgnvnQYT ZpkYbCVvTvo/dGc1o91a1Gay6rIpJUO4EtQXyVXROyMNy9Lz+qt+O6n+W2TJjrLRKrlr OjiiogTCN3rvu56utOk1p297ZcbYt1ppHPyFiv+F81jWWZvhFpuztnWT2FEHY4L26Hb0 NSoZyWcwt1obuQKPpE4JPRG5RPAgZ8pqMut/pegnaGchtt3/HgPatzyVP+3+r2p33JH4 zFcaNdHaN6O0PptVuhG0LP0UualOtq7s//NZNQ6YZorI0g1hjdTNl3ZhiiJO0jXiAUB/ QOOQ== X-Gm-Message-State: ALQs6tB/p3xmYAQ7+DNn0c8gAw+y5RN9vRn91vjfvXKiWqmjCEGqCKf+ 216gvqa0KGVBd3Zp4v6o8hqW0MFfQXPNGfQswqU= X-Google-Smtp-Source: AIpwx4+wOR/u6NnQEUyZCY2o17y6sDmGcmSD17SlQBas8EZtbOLLNueFMvrY+TUZwepMN2Pzb9Wid7PvWMbm3u2AI1o= X-Received: by 10.200.70.133 with SMTP id g5mr5967196qto.300.1523434949516; Wed, 11 Apr 2018 01:22:29 -0700 (PDT) MIME-Version: 1.0 Reply-To: Peter.Sewell@cl.cam.ac.uk Received: by 10.12.249.77 with HTTP; Wed, 11 Apr 2018 01:22:29 -0700 (PDT) In-Reply-To: <20180410172650.1608435887D@www.open-std.org> References: <20180410172650.1608435887D@www.open-std.org> From: Peter Sewell Date: Wed, 11 Apr 2018 09:22:29 +0100 X-Google-Sender-Auth: PlsJWN4z_vsre7ua7Dvgj28H6wA Message-ID: Subject: Re: (SC22WG14.15050) questions about N2219 proposed provenance changes To: Martin Sebor Cc: "sc22wg14@open-std.org" Content-Type: multipart/alternative; boundary="f4f5e80d762801239e05698e57f3" Sender: owner-sc22wg14@open-std.org Precedence: bulk --f4f5e80d762801239e05698e57f3 Content-Type: text/plain; charset="UTF-8" On 10 April 2018 at 18:26, Martin Sebor wrote: > I'm working through the changes proposed in the paper. > The proposal includes adding this text: > > Without the -fno-provenance option, when the lvalue conversion > is performed on an lvalue with pointer type, if it has the empty > provenance and the associated memory location is not within > the implementation-defined device memory, the behavior is > undefined. > > and > > A null pointer has the empty provenance. > > Wouldn't the first sentence imply that the second initialization > is undefined? > That might have been confusingly bad drafting on our part - we'll check (I'm in a rush right now, sorry). The intent was to require, for each load and store via a pointer value, to require that it has a valid provenance. > > void *p = 0; > void *q = p; > > Also, for the changes to the Equality operator, what does the note > in parentheses imply for the following modified version of the test > case from Q1: > > int f (int i) > { > int x = 1, y, z = 2; > int *p = &y + i; > > if (p != &x && p != &z) > return 0; > > return *p; > } > > Assuming the test fails and *p is evaluated, does the proposal > change the return statement to well-defined or does it leave > it undefined (as it is today)? > If the test fails then p has the numeric address of either x or z and the implementation decided in this instance not to take provenance into account in the comparison. Then the load of *p will give UB, as the provenance of the pointer value will still be that of the y allocation, but its numeric address is to x or z. best, p > > Thanks > Martin > --f4f5e80d762801239e05698e57f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 10 April 2018 at 18:26, Martin Sebor <msebor@gmail.com> wrote:
I'm working through the ch= anges proposed in the paper.
The proposal includes adding this text:

=C2=A0 Without the -fno-provenance option, when the lvalue conversion
=C2=A0 is performed on an lvalue with pointer type, if it has the empty
=C2=A0 provenance and the associated memory location is not within
=C2=A0 the implementation-defined device memory, the behavior is
=C2=A0 undefined.

and

=C2=A0 A null pointer has the empty provenance.

Wouldn't the first sentence imply that the second initialization
is undefined?

That might have been conf= usingly bad drafting on our part - we'll check
(I'm in a rush r= ight now, sorry).=C2=A0=C2=A0=C2=A0 The intent was to require, for each loa= d and
store via a pointer value, to require that it has a va= lid provenance.
=C2=A0

=C2=A0 void *p =3D 0;
=C2=A0 void *q =3D p;

Also, for the changes to the Equality operator, what does the note
in parentheses imply for the following modified version of the test
case from Q1:

=C2=A0 int f (int i)
=C2=A0 {
=C2=A0 =C2=A0 int x =3D 1, y, z =3D 2;
=C2=A0 =C2=A0 int *p =3D &y + i;

=C2=A0 =C2=A0 if (p !=3D &x && p !=3D &z)
=C2=A0 =C2=A0 =C2=A0 return 0;

=C2=A0 =C2=A0 return *p;
=C2=A0 }

Assuming the test fails and *p is evaluated, does the proposal
change the return statement to well-defined or does it leave
it undefined (as it is today)?

If the t= est fails then p has the numeric address of either x or z and the implement= ation decided in this instance not to take provenance into account in the c= omparison.

Then the load of *p will give UB, a= s the provenance of the pointer value will still be that of the y allocatio= n, but its numeric address is to x or z.=C2=A0

best,
=
p
=C2=A0

Thanks
Martin

--f4f5e80d762801239e05698e57f3--