From: Jeff King <peff@peff.net>
To: Victoria Dye <vdye@github.com>
Cc: Victoria Dye via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, derrickstolee@github.com, gitster@pobox.com
Subject: Re: [PATCH] read-cache: avoid misaligned reads in index v4
Date: Mon, 26 Sep 2022 13:35:04 -0400 [thread overview]
Message-ID: <YzHiyPkCgVHym3H4@coredump.intra.peff.net> (raw)
In-Reply-To: <e5954e90-6b5c-46a6-0842-b3d7d1e06b33@github.com>
On Mon, Sep 26, 2022 at 08:39:10AM -0700, Victoria Dye wrote:
> > So this can just be:
> >
> > ce->ce_stat_data.sd_mtime.sec = get_be32(ondisk + offsetof(struct ondisk_cache_entry, mtime));
> >
> > which is mercifully shorter.
> >
> > Assuming we dismiss the rest of what I said as not worth it for a
> > minimal fix, I do think that simplification is worth rolling a v2.
>
> That makes sense from a technical perspective, but I included the starting
> entry offset for readability reasons. It might be confusing to someone
> unfamiliar with C struct memory alignment to see every other 'get_be32'
> refer to the exact entry it's reading via the 'offsetof()', but have that
> information absent only for a few entries. And, the double 'offsetof()'
> would still be used by the 'mtime.nsec'/'ctime.nsec' fields anyway.
Ah, right, I wasn't looking close enough. I was thinking that you were
reading the whole struct via a single function call, but of course that
is not true with get_be32(), and the nsec loads just below make that
obvious.
> In any case, if this patch is intended to be a short-lived change on the way
> to a more complete refactor and/or I'm being overzealous on the readability,
> I'd be happy to change it. :)
No, I was just mis-reading it. I think what you've got here is a good
stopping point to fix the immediate problem.
-Peff
next prev parent reply other threads:[~2022-09-26 17:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-23 19:43 [PATCH] read-cache: avoid misaligned reads in index v4 Victoria Dye via GitGitGadget
2022-09-23 21:39 ` Jeff King
2022-09-23 22:04 ` Junio C Hamano
2022-09-26 15:39 ` Victoria Dye
2022-09-26 17:35 ` Jeff King [this message]
2022-09-26 19:08 ` Jeff King
2022-09-26 19:31 ` Jeff King
2022-09-26 23:02 ` Junio C Hamano
2022-09-25 8:25 ` Phillip Wood
2022-09-26 17:54 ` Junio C Hamano
2022-09-28 17:19 ` [PATCH v2] " Victoria Dye via GitGitGadget
2022-09-28 17:34 ` 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=YzHiyPkCgVHym3H4@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=derrickstolee@github.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
--cc=vdye@github.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 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 NNTP newsgroup(s).