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

[Martin Sebor <msebor@gmail.com>]

On 12/11/18 4:19 PM, Jason Merrill wrote:
> 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.

Are there any other suggestions for changes or should I take
this as an approval to commit the updated patch?

https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00740.html

Martin