git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jessica Clarke <jrtc27@jrtc27.com>
To: Taylor Blau <me@ttaylorr.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] apply: Avoid ambiguous pointer provenance for CHERI/Arm's Morello
Date: Thu, 6 Jan 2022 22:57:42 +0000	[thread overview]
Message-ID: <C2DD77CA-D1F1-45ED-912F-C4532EB2720C@jrtc27.com> (raw)
In-Reply-To: <YddySiBCOOYYKDmC@nand.local>

]On 6 Jan 2022, at 22:50, Taylor Blau <me@ttaylorr.com> wrote:
> 
> On Wed, Jan 05, 2022 at 01:23:10PM +0000, Jessica Clarke wrote:
>> [...] In most cases this is clear, as normally at least one operand is
>> provably a plain integer, but if both operands are uintptr_t and have
>> no indication they're just plain integers then it is ambiguous, and
>> the current implementation will arbitrarily, but deterministically,
>> pick the left-hand side, due to empirical evidence that it is more
>> likely to be correct.
> 
> Wouldn't a simpler, less invasive fix be to instead write the expression
> so that the left-hand operand is a pointer? IOW, shouldn't the following
> work (with no other changes):
> 
>    ent->util = (void *)((uintptr_t)what | ent->util);
> 
> ?
> 
> (I dropped the explicit cast on the right-hand side, since ent->util is
> already a uintptr_t, and the left-hand side has an explicit cast, so
> there isn't any type promotion going on here).

That would still warn as it’s still ambiguous. It just happens that the
arbitrary choice picks the right side. Better to clean up the code to
remove the ambiguity and clarify it to the programmer.

Jess


  reply	other threads:[~2022-01-06 22:57 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-05 13:23 [PATCH] apply: Avoid ambiguous pointer provenance for CHERI/Arm's Morello Jessica Clarke
2022-01-05 16:39 ` Konstantin Khomoutov
2022-01-05 16:40   ` Jessica Clarke
2022-01-06 22:50 ` Taylor Blau
2022-01-06 22:57   ` Jessica Clarke [this message]
2022-01-06 22:53 ` Junio C Hamano
2022-01-06 23:02   ` Jessica Clarke
2022-01-06 23:41     ` Junio C Hamano
2022-01-07 12:16   ` René Scharfe
2022-01-07 13:00     ` Jessica Clarke
2022-01-07 19:40     ` Junio C Hamano
2022-01-08  0:04       ` René Scharfe
2022-01-08  0:51         ` Junio C Hamano
2022-01-07 23:25     ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=C2DD77CA-D1F1-45ED-912F-C4532EB2720C@jrtc27.com \
    --to=jrtc27@jrtc27.com \
    --cc=git@vger.kernel.org \
    --cc=me@ttaylorr.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).