Re: [PATCH v1] Travis: also test on 32-bit Linux
- From
Jeff King <peff@peff.net>
- Date
- Mar 5, 2017, 11:46 UTC
- Message-ID
- <20170305114638.x7g767js2m3othga@sigill.intra.peff.net>
- In-Reply-To
- <20170305113618.ko2jymle4n5f2b5l@sigill.intra.peff.net>
On Sun, Mar 05, 2017 at 06:36:19AM -0500, Jeff King wrote:
> I grepped for 'memcpy.*sizeof' and found one other case that's not a > bug, but is questionable.
And here's the fix for that case. It can be applied separately from the other patch if need be.
-- >8 -- Subject: [PATCH] ewah: fix eword_t/uint64_t confusion
The ewah subsystem typedefs eword_t to be uint64_t, but some code uses a bare uint64_t. This isn't a bug now, but it's a potential maintenance problem if the definition of eword_t ever changes. Let's use the correct type.
Note that we can't use COPY_ARRAY() here because the source and destination point to objects of different sizes. For that reason we'll also skip the usual "sizeof(*dst)" and use the real type, which should make it more clear that there's something tricky going on.
Signed-off-by: Jeff King <peff@peff.net> --- ewah/ewah_io.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/ewah/ewah_io.c b/ewah/ewah_io.c index 61f6a4357..f73210973 100644 --- a/ewah/ewah_io.c +++ b/ewah/ewah_io.c @@ -142,8 +142,8 @@ int ewah_read_mmap(struct ewah_bitmap *self, const void *map, size_t len) * the endianness conversion in a separate pass to ensure * we're loading 8-byte aligned words. */ - memcpy(self->buffer, ptr, self->buffer_size * sizeof(uint64_t)); - ptr += self->buffer_size * sizeof(uint64_t); + memcpy(self->buffer, ptr, self->buffer_size * sizeof(eword_t)); + ptr += self->buffer_size * sizeof(eword_t); for (i = 0; i < self->buffer_size; ++i) self->buffer[i] = ntohll(self->buffer[i]);
-- 2.12.0.426.g9d5d0eeae