From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from brightrain.aerifal.cx (brightrain.aerifal.cx [216.12.86.13]) by sourceware.org (Postfix) with ESMTPS id CACC039878DD for ; Tue, 22 Sep 2020 16:25:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org CACC039878DD Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=libc.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=dalias@libc.org Date: Tue, 22 Sep 2020 12:25:49 -0400 From: Rich Felker To: libc-coord@lists.openwall.com Cc: Florian Weimer , Libc-alpha , gcc@gcc.gnu.org, libstdc++@gcc.gnu.org Subject: Re: [libc-coord] Re: Expose 'array_length()' macro in or Message-ID: <20200922162549.GH3265@brightrain.aerifal.cx> References: <946e9377-0558-3adf-3eb9-38c507afe2d0@gmail.com> <874knr8qyl.fsf@oldenburg2.str.redhat.com> <875z875si2.fsf@oldenburg2.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2020 16:25:51 -0000 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