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> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King committed
Mar 5, 2017 at 06:46 UTC
3255e512a8594cc5f811aea0dd769429c0f0d614
1 file changed
+2
-2
ewah/ewah_io.c
+2
-2
@@ -133,8 +133,8 @@ int ewah_read_mmap(struct ewah_bitmap *self, void *map, size_t len)
133
* the endianness conversion in a separate pass to ensure
134
* we're loading 8-byte aligned words.
135
*/
136
- memcpy(self->buffer, ptr, self->buffer_size * sizeof(uint64_t));
137
- ptr += self->buffer_size * sizeof(uint64_t);
136
+ memcpy(self->buffer, ptr, self->buffer_size * sizeof(eword_t));
137
+ ptr += self->buffer_size * sizeof(eword_t);
138
139
for (i = 0; i < self->buffer_size; ++i)
140
self->buffer[i] = ntohll(self->buffer[i]);