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.