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

[Jason Merrill <jason@redhat.com>]

On 12/11/18 6:08 PM, Martin Sebor wrote:
> On 12/11/18 3:52 PM, Marek Polacek wrote:
>> On Tue, Dec 11, 2018 at 03:46:37PM -0700, Martin Sebor wrote:
>>> 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.
>>
>> The reason was that C++ scoped enumerations don't implicitly convert to
>> integral types.
> 
> I'm not sure we're talking about the same thing.  There is no
> conversion in the use case I described, the attribute argument
> just refers to the function parameter, and the function is called
> with an argument of the enumerated type of the parameter.  Like
> this:
> 
>    enum class Alignment { a4 = 4, a8 = 8 };
> 
>    __attribute__ ((alloc_align (1))) void*
>    aligned_alloc (Alignment, size_t);
> 
>    void *p = aligned_alloc (Alignment::a8, 32);
> 
> My question is: if we think it makes sense to accept this use
> case with ordinary enums why would we not want to make it possible
> with scoped enums?  People tend to think of the latter as preferable
> over the former.

OK, I suppose it's reasonable to allow scoped enums as well.

Jason