This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] array_length, array_end macros for internal use
- From: Florian Weimer <fweimer at redhat dot com>
- To: Paul Eggert <eggert at cs dot ucla dot edu>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Sat, 21 Oct 2017 22:42:45 +0200
- Subject: Re: [PATCH] array_length, array_end macros for internal use
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=fweimer at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com BD14E4E33E
- References: <9c9b0fdf-5b87-7e58-0b0b-c8469e56c0a4@redhat.com> <804c8f31-8c9a-5b77-f7e3-d94d61d4c8e7@cs.ucla.edu>
On 10/21/2017 08:10 PM, Paul Eggert wrote:
Thanks, this is a good thing to write a macro for. A couple of comments:
The Emacs internals use the name ARRAYELTS for the same concept. I
recall that the name was discussed at some length when the macro was
introduced. "length" is perhaps not the best word to use here, since
array_length ("foo") != strlen ("foo").
I didn't want to use array_size because of the potential confusion with
sizeof.
And capitalization is
appropriate when a macro cannot be written as a function. So I suggest
the name ARRAYELTS, or something like it.
glibc has not followed this style for some time (see libc_hidden_def,
__libc_lock_lock etc.), and the C++ version (if we need it) will be
written as a function anyway.
+#define array_end(var) &(var)[array_length (var)]
We haven't felt the need for such a macro in Emacs.
I saw a couple of uses in stdio-common, so I added it.
If there's need in
glibc, the definiens should be parenthesized so that (mis?)uses like (&
ARRAYEND (var)->firstmember) are handled properly.
Thanks, fixed in my local version.
Florian