Re: [Intel-gfx] [PATCH v10 3/9] compiler_types.h: Add assert_type to catch type mis-match while compiling

[Andi Shyti <andi.shyti@linux.intel.com>]

Hi Rasmus,

Thanks for dropping in,

[...]

> >> + * @t1: data type or variable
> >> + * @t2: data type or variable
> >> + *
> >> + * The first and second arguments can be data types or variables or mixed (the
> >> + * first argument is the data type and the second argument is variable or vice
> >> + * versa). It determines whether the first argument's data type and the second
> >> + * argument's data type are the same while compiling, and it breaks compile if
> >> + * the two types are not the same.
> >> + * See also assert_typable().
> >> + */
> >> +#define assert_type(t1, t2) _Static_assert(__same_type(t1, t2))
> > 
> > In C11 _Static_assert is defined as:
> > 
> >   _Static_assert ( constant-expression , string-literal ) ;
> > 
> > While
> > 
> >   _Static_assert ( constant-expression ) ;
> > 
> > is defined in C17 along with the previous. I think you should add
> > the error message as a 'string-literal'.
> 
> See how static_assert() is defined in linux/build_bug.h, and let's avoid
> using _Static_assert directly. So this should IMO just be

yes, our definition of static_assert() is against the C11
specification, which should define it as:

  #define static_assert _Static_assert

this doesn't make me a big fan of it. But, because it's widely
used, I think it should be used here as well, as you are
suggesting.

> #define assert_same_type(t1, t2) static_assert(__same_type(t1, t2))
> 
> (including the naming of the macro; I don't think "assert_type" is a
> good name). No need to add an explicit string literal, the name of the
> macro and the constant expression itself are plenty to explain what is
> being asserted (with the latter being the reason the string was made
> optional).

The string literal would be "__same_type(t1, t2)", right? I would
still use something more explicit... up to Gwan-gyeong.

Thanks,
Andi