Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 22 Sep 2020 12:25:49 -0400
From: Rich Felker <>
Cc: Florian Weimer <>,
	Libc-alpha <>,,
Subject: Re: Re: Expose 'array_length()' macro in <sys/cdefs.h>
 or <sys/param.h>

On Mon, Sep 21, 2020 at 02:47:51PM +0200, Alejandro Colomar wrote:
> [[ CC += libc-coord at ]]

I missed the beginning of this so perhaps it's already been discussed,
but I don't see how cdefs.h is a remotely reasonable place for this.
cdefs.h is included by all glibc headers and would expose anything it
defines into the namespace, so it can't define anything not in the
reserved namespace. Moreover, the whole purpose of cdefs.h is for
internal use by glibc's headers; the things it defines are not public
interfaces. So even fixing the name to be __array_length or something
would not solve the problem; rather it would exacerbate the problem of
applications treating internal glibc glue as stuff for their

The alternative of sys/param.h is at least non-offensive, but it's
full of messy legacy macros and I don't think it's something that new
applications should be using. It also might conflict with equivalent
macros in existing software using this header.

Is there really a reason to want a nonstandard macro like this to do
something that's already trivial to do in the base language and has a
standard idiom (sizeof x / sizeof *x)?


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.