This is the mail archive of the 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: [PATCH] accept all C integer types in function parameters referenced by alloc_align (PR 88363)

On Tue, Dec 11, 2018 at 08:17:26AM +0100, Jakub Jelinek wrote:
> On Mon, Dec 10, 2018 at 04:30:11PM -0700, Martin Sebor wrote:
> > Some of my testing exposed a minor problem in GCC 9's validation
> > of the type of function parameters referred to by attribute
> > positional arguments.  Whereas GCC 8 accepts all C integer types,
> > including enumerated types, such as:
> > 
> >   enum AllocAlign { Align16 = 16, Align32 = 32 };
> > 
> >   __attribute__ ((alloc_align (1))) void*
> >   alloc (size_t, enum AllocAlign)
> > 
> > GCC 9 only accepts signed and unsigned integer types.  This change
> > (introduced by myself) was unintentional, and a fix for it is in
> > the attached trivial patch.  I plan to commit it without approval
> > in the next day or so unless any concerns or suggestions come up.
> There is nothing obvious about this, so please don't commit it without
> approval.  GCC 8 and older used to accept

I agree that this isn't an obvious change.

> even float or void * or struct arguments and just ignored them.
> I think we need to discuss what types we want to allow without warnings and
> what we should warn.
> As I wrote in the PR, I believe e.g. using alloc_align/alloc_size with
> bool/_Bool is just a clear bug, you can store 0 or 1 in there, but e.g.
> alignment 0 doesn't make sense.
> Enums are on the border line, I'll defer to C/C++ maintainers whether we
> want to include that or not.

For C, I'd allow them (and I think I've made a change to that effect in the
past in the C FE).


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