On 19/01/17 21:52, Eric Blake wrote: > On the qemu list, it was pointed out that code that uses > ARRAY_CARDINALITY() might still compile even after it has been > refactored to use a pointer (probably conversion of an array into > dynamic allocation), but that you can add a compile-time check with > new-enough gcc/clang to catch this. > > I'm also wondering if we should promote ARRAY_CARDINALITY into a > full-fledged gnulib module (several gnulib files define it in .c files, > but leave projects to re-define their own; coreutils' is in system.h). > > The qemu list spells their macro ARRAY_SIZE, and > QEMU_BUILD_BUG_ON_ZERO(x) is equivalent to our verify_expr(!x, 0), but > I'm wondering if we should similarly strengthen coreutils' macro (with > appropriate guards for new-enough gcc, since we target more compilers > than qemu): > > https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg04118.html > > +/* > + * &(x)[0] is always a pointer - if it's same type as x then the > argument is a > + * pointer, not an array. > + */ > +#define QEMU_IS_ARRAY(x) (!__builtin_types_compatible_p(typeof(x), \ > + typeof(&(x)[0]))) > #ifndef ARRAY_SIZE > -#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0])) > +#define ARRAY_SIZE(x) ((sizeof(x) / sizeof((x)[0])) + \ > + QEMU_BUILD_BUG_ON_ZERO(!QEMU_IS_ARRAY(x))) > #endif
gnulib module + extra checks + name change to ARRAY_SIZE sound good! For a convenience feature, ARRAY_CARDINALITY is not a convenient name. thanks! Pádraig
