Expose 'array_length()' macro in <sys/cdefs.h> or <sys/param.h>

Alejandro Colomar colomar.6.4.3@gmail.com
Mon Sep 21 10:11:43 GMT 2020


[[
CC += libc-coord@sourceware.org
CC += gcc@gcc.gnu.org
CC += libstdc++@gcc.gnu.org
]]

Hi Florian,

On 2020-09-21 10:38, Florian Weimer wrote:
 > * Alejandro Colomar via Libc-alpha:
 >
 >> I'd like to propose exposing the macro 'array_length()' as defined in
 >> 'include/array_length.h' to the user.
 >
 > It would need a good C++ port, probably one for C++98 and another one
 > for C++14 or later.

For C++, I use the following definition:


	#include <cassert>
	#include <sys/cdefs.h>
	#include <type_traits>


	#define is_array__(a)	(std::is_array <__typeof__(a)>::value)

	#define must_be_array(arr)				\
		static_assert(is_array__(arr), "Must be an array !")


	#define array_length(arr)	(			\
	{							\
		must_be_array(arr);				\
		__arraycount((arr));				\
	}							\
	)


This solves the problem about G++ not having
__builtin_types_compatible_p().

However, there are a few problems:

1) This doesn't work for VLAs (GNU extension).
    I couldn't find a way to do it.  Maybe I should file a bug in GCC.

2) Also, this requires C++11; I don't know how to do it for older C++.
    Again, support from the compiler would be great.

3) The macro can't be used in the same places as the C version,
    because of the `({})`.
    The `0 * sizeof(struct{...})` trick doesn't work in C++ due to:
	error: types may not be defined in 'sizeof' expressions

 >
 >> Libbsd provides '__arraycount()' in <sys/cdefs.h> and some BSDs provide
 >> 'nitems()' in <sys/param.h>, so any of those 2 headers may be a good
 >> place to do it.
 >
 > In this case, I would prefer nitems in <sys/param.h>, given that there
 > is precedent for it.  <sys/cdefs.h> seems to be a bit drastic for a new
 > macro with such a common name; it would create widespread build
 > breakage.

Ok.  I guess you would use 'nitems()' name, right?

 >
 > Maybe also ask on the libc-coord list.

Ok.  Added CCs.

 >
 > Thanks,
 > Florian
 >

Thanks,

Alex


More information about the Gcc mailing list