Re: [PATCH v1] Travis: also test on 32-bit Linux

From: René Scharfe <l.s.r@web.de>
Date: Mar 10, 2017, 00:14 UTC
Message-ID: <63a6ec61-653d-6307-4739-2ebaa8dbde35@web.de>
In-Reply-To: <20170305113618.ko2jymle4n5f2b5l@sigill.intra.peff.net>

Am 05.03.2017 um 12:36 schrieb Jeff King:

Show 6 quoted lines

> 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:

Show 12 quoted lines

>   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é