Re: [PATCH] accept all C integer types in function parameters referenced by alloc_align (PR 88363)

[Martin Sebor <msebor at gmail dot com>]

On 12/11/18 1:47 PM, Jakub Jelinek wrote:
> On Tue, Dec 11, 2018 at 01:36:58PM -0700, Martin Sebor wrote:
> > Attached is an updated version of the patch that restores
> > the original behavior for the positional argument validation
> > (i.e., prior to r266195) for integral types except bool as
> > discussed.
>
> I thought Jason wanted to also warn for scoped enums in C++.

I missed that.  It seems needlessly restrictive to me to reject
the preferred kind of an enum when ordinary enums are accepted.
Jason, can you confirm that you really want a warning for B
below when there is none for A (GCC 8 doesn't complain about
either, Clang complains about both, ICC about neither when
using alloc_size -- it doesn't understand alloc_align):

  enum A { /* ... */ };
  __attribute__ ((alloc_align (1))) void* f (A);

  enum class B { /* ... */ };
  __attribute__ ((alloc_align (1))) void* g (B);

The only use case I can think of for enums is in APIs that try
to restrict the available choices of alignment to those of
the enumerators.  In that use case, I would expect it to make
no difference whether the enum is ordinary or the scoped kind.

> > +      else if (code == INTEGER_TYPE)
> > +	/* For integers, accept enums, wide characters and other types
> > +	   that match INTEGRAL_TYPE_P except for bool.  */
> > +	type_match = (INTEGRAL_TYPE_P (argtype)
> > +		      && TREE_CODE (argtype) != BOOLEAN_TYPE);
>
> So it would better be:
> 	type_match = (TREE_CODE (argtype) == INTEGER_TYPE
> 		      || (TREE_CODE (argtype) == ENUMERAL_TYPE
> 			  && !ENUM_IS_SCOPED (argtype)));
>
> > --- gcc/doc/extend.texi	(revision 266966)
> > +++ gcc/doc/extend.texi	(working copy)
> > @@ -2471,7 +2471,9 @@ The @code{aligned} attribute can also be used for
> >   @item alloc_align (@var{position})
> >   @cindex @code{alloc_align} function attribute
> >   The @code{alloc_align} attribute may be applied to a function that
> > -returns a pointer and takes at least one argument of an integer type.
> > +returns a pointer and takes at least one argument of an integer or
> > +enumerated type, but not @code{bool}.  Arguments of other types are
> > +diagnosed.
>
> The keyword is _Bool in C, so wouldn't it be better to say but not Boolean
> type or but not @code{bool} or @code{_Bool}?

It makes little difference.  Established practice in the manual
is @code{bool} (14 occurrences).  There are just three instances
of @code{_Bool} in prose in doc/*.texi.  It's simpler to refer
to @code{bool} unless we are specifically talking about the C
keyword/type.

Martin