Ping: https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00740.html
On 12/18/18 2:42 PM, Martin Sebor wrote:
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
