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 <p...@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
