From: Junio C Hamano <gitster@pobox.com>
To: Jessica Clarke <jrtc27@jrtc27.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] apply: Avoid ambiguous pointer provenance for CHERI/Arm's Morello
Date: Thu, 06 Jan 2022 15:41:00 -0800 [thread overview]
Message-ID: <xmqqwnjca0vn.fsf@gitster.g> (raw)
In-Reply-To: <BE9D3BD5-EC19-4881-872D-CEB4039A382D@jrtc27.com> (Jessica Clarke's message of "Thu, 6 Jan 2022 23:02:23 +0000")
Jessica Clarke <jrtc27@jrtc27.com> writes:
>> I actually wonder if it results in code that is much easier to
>> follow if we did:
>>
>> * Introduce an "enum apply_symlink_treatment" that has
>> APPLY_SYMLINK_GOES_AWAY and APPLY_SYMLINK_IN_RESULT as its
>> possible values;
>>
>> * Make register_symlink_changes() and check_symlink_changes()
>> work with "enum apply_symlink_treatment";
>>
>> * (optional) stop using string_list() to store the symlink_changes;
>> use strintmap and use strintmap_set() and strintmap_get() to
>> access its entries, so that the ugly implementation detail
>> (i.e. "the container type we use only has a (void *) field to
>> store caller-supplied data, so we cast an integer and a pointer
>> back and forth") can be safely hidden.
>
> Those would be better if you want a less-minimal change.
The first two at least would make an understandable change, as
opposed to the code as posted, which is totally opaque why we need
to take size_t and cast it to uintptr_t in the first place.
I have no confidence in myself that I would not accept a future
patch that reverts the change made by this patch happily. I usually
try to be careful to go back to the originating commit by running
"blame" on the preimage and may find your commit, but that's only
"usually". If I were to work only with the file contents after
applying this patch, because no clue ...
ent->util = (void *)((uintptr_t)what | ((uintptr_t)ent->util));
... on this line of code hints why we must be called with size_t and
have to cast it here, instead of working with uintptr_t throughout,
I am reasonably sure I'd happily take such a patch and break your
"fix" here.
If we make the code pass around the enum, have a temporary variable
of the same enum type to compute the next value we stuff in
ent->util, and make an assignment of that enum value to ent->util,
it is much less likely that I'd blindly accept a patch to take us
back to deal with uintptr_t directly.
next prev parent reply other threads:[~2022-01-06 23:41 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
2022-01-06 22:53 ` Junio C Hamano
2022-01-06 23:02 ` Jessica Clarke
2022-01-06 23:41 ` Junio C Hamano [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqwnjca0vn.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jrtc27@jrtc27.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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.