This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] [PATCH] Add __array_size keyword


On Mon, Feb 15, 2016 at 03:05:36PM +0100, Marek Polacek wrote:
> On Sat, Feb 13, 2016 at 03:16:49AM +0000, Stuart Brady wrote:
> > I will look into submitting a PR for this properly soon, but will not
> > mind if someone wants to take this task upon themselves instead,
> > especially as we are into the release phase for GCC 6 and this may be
> > an issue worth fixing.  (Note that Debian's GCC 5.3.1 is also affected.)
> 
> Sure, I've just filed this:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69824

Thank you!

> > For a hypothetical change to the C standard itself, I think one might use
> > the name "_ArraySize", but for a non-standard extension this would not be
> > appropriate.  I think "__array_size" is fine, though, and is consistent
> > with "__alignof".
> 
> Please no CamelCase, that's ugly ;).  I also think that "__array_size" is fine.

Okay.  I was wondering about __arraysize, __array_len, or some such
thing but I suppose one just needs to pick something.  ARRAY_SIZE seems
common as macro name that I find __array_size to be immediately obvious.
Certainly, the name is something that doesn't need to be decided just now
although it's better to consider alternatives sooner rather than later.

Hypothetically, I suppose _Array_Size, _Array_size or _Arraysize would
all be better than the CamelCase verison.


> (I haven't had time so far to read the patch.)

Jospeh's point that documentation and testcases are of much more value is
good one, and reveals a problem with my patch.  It does not work in the
following case:

   vla-array-size.c:19:55: error: invalid use of flexible array member
    int foo6(int a, int b[*][*], int c[static __array_size(*b)]);
                                                          ^

sizeof() *does* work in this case -- my test is based on gcc.dg/vla-5.c
which uses sizeof() instead.  __array_size(*b) works fine the function
body but not in the prototype, and also works fine with C99 variable
length arrays.

This message has been borrowed from c_incomplete_type_error(), along with
the test for TYPE_DOMAIN (type) && TYPE_MAX_VALUE (TYPE_DOMAIN (type)).

Unfortunately, I'm at a loss to say whether TYPE_MAX_VALUE should be
set in this instance, or whether I should be going about things
differently.  It seems interesting that TYPE_SIZE_UNIT (type) is set
but TYPE_MAX_VALUE (TYPE_DOMAIN (type)) is not.  Can anyone help?

Also, it's not obvious to me whether I need to consider the case of
TYPE_MIN_VALUE (TYPE_DOMAIN (type)) being nonzero.
-- 
Many thanks,
Stuart Brady


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]