From: Jeff King Date: Sun, 05 Mar 2017 11:46:38 GMT Subject: Re: [PATCH v1] Travis: also test on 32-bit Linux 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 --- 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