ewah: fix eword_t/uint64_t confusion
authorJeff King <peff@peff.net>
Sun, 5 Mar 2017 11:46:38 +0000 (06:46 -0500)
committerJunio C Hamano <gitster@pobox.com>
Mon, 6 Mar 2017 20:03:40 +0000 (12:03 -0800)
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>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
ewah/ewah_io.c

index f7f700e..84eaf89 100644 (file)
@@ -133,8 +133,8 @@ int ewah_read_mmap(struct ewah_bitmap *self, 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]);