_Static_assert (N1330) & variants

[Hallvard B Furuseth]

C99 expanded the assert() argument from int to scalar, yet
N1330/N1362 _Static_assert() takes an integer. I think they
should take the same argument type. Unless the C1X draft
is just copying C++ and C++ has the same mismatch?

Sometimes I also want a compile-time assert _expression_. Mostly for
macros that need to check that the arguments are valid, maybe because
they are making nonstandard assumptions.

Can _Static_assert be used inside a struct? That'd allow the above:

/* Return 0, but force a compile error if !c */
#define ASSERTZ(c, text) \
(sizeof(struct { _Static_assert(c, text); int Assertz; }) && 0)

(BTW, such a macro might be included in <assert.h> too.)

If it's not allowed, I could keep using a variant of the old hack which
_Static_assert is designed to improve on. (Force constraint violations.)
Seems a pity though:

#define ASSERTZ(c) \
(sizeof(struct {int Assertz1[(c)?9:-9]; int Assertz2:(c)?9:-9;}) && 0)

--
Hallvard

[Keith Thompson]

Hallvard B Furuseth <h.b.fu...@usit.uio.no> writes:
> C99 expanded the assert() argument from int to scalar, yet
> N1330/N1362 _Static_assert() takes an integer. I think they
> should take the same argument type. Unless the C1X draft
> is just copying C++ and C++ has the same mismatch?

I don't think non-integer scalars would be useful.

It takes a constant expression. Floating-point expressions would be
either unreliable or obvious; consider:
_Static_assert(1.0/3.0*3.0, "Shrug");

And address constants wouldn't be terribly useful, since anything
other than a null pointer constant is non-zero.

> Sometimes I also want a compile-time assert _expression_. Mostly for
> macros that need to check that the arguments are valid, maybe because
> they are making nonstandard assumptions.
>
> Can _Static_assert be used inside a struct? That'd allow the above:

[snip]

Yes, it appears that the grammar is designed to permit it. With some
omissions:

struct-or-union-specifier:
struct-or-union identifier(opt) { struct-declaration-list }

struct-declaration-list:
struct-declaration
struct-declaration-list struct-declaration

struct-declaration:
specifier-qualifier-list struct-declarator-list ;
static_assert-declaration

Of course a static_assert-declaration is also a declaration.

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Hallvard B Furuseth]

Keith Thompson writes:
>Hallvard B Furuseth <h.b.fu...@usit.uio.no> writes:
>> C99 expanded the assert() argument from int to scalar, yet
>> N1330/N1362 _Static_assert() takes an integer. I think they
>> should take the same argument type. Unless the C1X draft
>> is just copying C++ and C++ has the same mismatch?
>
> I don't think non-integer scalars would be useful.
>
> It takes a constant expression. Floating-point expressions would be
> either unreliable or obvious; consider:
> _Static_assert(1.0/3.0*3.0, "Shrug");
>
> And address constants wouldn't be terribly useful, since anything
> other than a null pointer constant is non-zero.

Maybe so, but if someone does find a use for such an expression he may
get a surprise if _Static_assert() converts its argument to an integer.

Hmm... if it does. Section 6.7.9 in C1X draft N1362 does say

Semantics
3 The constant expression shall be an integer constant expression.

but that's the Semantics section, so I suppose it's not a constraint
violation of the expression is not an integer. But it then goes on with

If the value of the constant expression compares unequal to 0, the
declaration has no effect. Otherwise, the constraint is violated
and the implementation shall produce a diagnostic message that (...)

A constraint which is not in the Constraints section? Why not move it
to the Constraints section, along with saying that the type is an
integer constant expression? The Semantics section could simply
describe the diagnostic message.

>> [snip]

>> Can _Static_assert be used inside a struct? That'd allow the above:
> [snip]
>
> Yes, it appears that the grammar is designed to permit it. With some
> omissions:

> [snip]

Ah, of course. Thanks.

--
Hallvard