[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 22 Sep 2020 12:25:49 -0400
From: Rich Felker <dalias@...c.org>
To: libc-coord@...ts.openwall.com
Cc: Florian Weimer <fweimer@...hat.com>,
Libc-alpha <libc-alpha@...rceware.org>, gcc@....gnu.org,
libstdc++@....gnu.org
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 lists.openwall.com ]]
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
consumption.
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)?
Rich
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.
