Am 05.03.2017 um 12:36 schrieb Jeff King:
I grepped for 'memcpy.*sizeof' and found one other case that's not a
bug, but is questionable.
Of the "good" cases, I think most of them could be converted into
something more obviously-correct, which would make auditing easier. The
three main cases I saw were:
3. There were a number of alloc-and-copy instances. The copy part is
the same as (2) above, but you have to repeat the size, which is
potentially error-prone. I wonder if we would want something like:
#define ALLOC_COPY(dst, src) do { \
(dst) = xmalloc(sizeof(*(dst))); \
COPY_ARRAY(dst, src, 1); \
while(0)
That avoids having to specify the size at all, and triggers a
compile-time error if "src" and "dst" point to objects of different
sizes.
Or you could call it DUP or similar. And you could use ALLOC_ARRAY in
its definition and let it infer the size implicitly (don't worry too
much about the multiplication with one):
#define DUPLICATE_ARRAY(dst, src, n) do { \
ALLOC_ARRAY((dst), (n)); \
COPY_ARRAY((dst), (src), (n)); \
} while (0)
#define DUPLICATE(dst, src) DUPLICATE_ARRAY((dst), (src), 1)
But do we even want such a thing? Duplicating objects should be rare,
and keeping allocation and assignment/copying separate makes for more
flexible building blocks. Adding ALLOC (and CALLOC) for single objects
could be more widely useful, I think.
René