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
