From: Junio C Hamano <gitster@pobox.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: git@vger.kernel.org, Michael Cree <mcree@orcon.net.nz>,
Linus Torvalds <torvalds@linux-foundation.org>,
Nicolas Pitre <nico@fluxnic.net>
Subject: Re: [PATCH lt/block-sha1 0/2 v3] block-sha1: avoid pointer conversion that violates alignment constraints
Date: Sun, 22 Jul 2012 22:42:23 -0700 [thread overview]
Message-ID: <7vboj7nidc.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <20120723052605.GA13728@burratino> (Jonathan Nieder's message of "Mon, 23 Jul 2012 00:28:02 -0500")
Jonathan Nieder <jrnieder@gmail.com> writes:
> Junio C Hamano wrote:
>> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>>> The big-endian part was just my idiocy, sorry.
>>
>> Hrm, do we want an update log message for 1/2 then?
>
> Hm, I thought all the crazy had been eliminated already.
>
> *looks again*
>
> I guess "using a single 32-bit load" makes it sound like it's using a
> big-endian load instead of a load followed by twiddling in registers.
>
> Simplest fix would be to drop the phrase "by using a single 32-bit
> load", leaving "... and gcc takes full advantage, resulting in a whole
> bunch of unaligned access traps."
I was just being stupid, misread the original code and did not
realize that the generic code quoted in your log message:
#define get_be32(p) ( \
... byte-at-a-time implementation )
is not limited to big endian boxes [*1*]. So I think the message is
fine as-is.
[Footnote]
*1* In other words, the ntohl(*(uint *)(p)) is used only on selected
little endian boxes, but that does not mean the generic code was
big-endian only. Little endian boxes that are not listed in #if
block do use the generic byte-at-a-time macro.
next prev parent reply other threads:[~2012-07-23 5:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-22 23:35 [PATCH lt/block-sha1 0/2 v3] block-sha1: avoid pointer conversion that violates alignment constraints Jonathan Nieder
2012-07-22 23:39 ` [PATCH 1/2] " Jonathan Nieder
2012-07-22 23:40 ` [PATCH 2/2] block-sha1: put expanded macro parameters in parentheses Jonathan Nieder
2012-07-23 4:28 ` [PATCH lt/block-sha1 0/2 v3] block-sha1: avoid pointer conversion that violates alignment constraints Junio C Hamano
2012-07-23 4:51 ` Jonathan Nieder
2012-07-23 5:10 ` Junio C Hamano
2012-07-23 5:28 ` Jonathan Nieder
2012-07-23 5:42 ` Junio C Hamano [this message]
2012-07-23 6:29 ` [PATCH/RFC 3/1] Makefile: BLK_SHA1 does not require fast htonl() and unaligned loads Jonathan Nieder
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=7vboj7nidc.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jrnieder@gmail.com \
--cc=mcree@orcon.net.nz \
--cc=nico@fluxnic.net \
--cc=torvalds@linux-foundation.org \
/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.