Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #61640 > unrolled thread

Implementing static_assert

Back to article view | Back to comp.lang.c

Contents

  Implementing static_assert jacobnavia <jacob@jacob.remcomp.fr> - 2015-05-06 21:44 +0200
    Re: Implementing static_assert Keith Thompson <kst-u@mib.org> - 2015-05-06 13:28 -0700
      Re: Implementing static_assert jacobnavia <jacob@jacob.remcomp.fr> - 2015-05-06 22:55 +0200
        Re: Implementing static_assert Keith Thompson <kst-u@mib.org> - 2015-05-06 14:30 -0700
          Re: Implementing static_assert Martin Shobe <martin.shobe@yahoo.com> - 2015-05-06 18:07 -0500
            Re: Implementing static_assert Keith Thompson <kst-u@mib.org> - 2015-05-06 17:34 -0700
            Re: Implementing static_assert David Brown <david.brown@hesbynett.no> - 2015-05-07 09:44 +0200
        Re: Implementing static_assert Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-07 12:37 -0700
    Re: Implementing static_assert David Brown <david.brown@hesbynett.no> - 2015-05-07 10:11 +0200
      Re: Implementing static_assert Ian Collins <ian-news@hotmail.com> - 2015-05-07 22:13 +1200
        Re: Implementing static_assert jacobnavia <jacob@jacob.remcomp.fr> - 2015-05-07 12:24 +0200
          Re: Implementing static_assert Ian Collins <ian-news@hotmail.com> - 2015-05-07 22:33 +1200
            Re: Implementing static_assert David Brown <david.brown@hesbynett.no> - 2015-05-07 14:30 +0200
      Re: Implementing static_assert Philip Lantz <prl@canterey.us> - 2015-05-07 03:53 -0700
        Re: Implementing static_assert David Brown <david.brown@hesbynett.no> - 2015-05-07 14:21 +0200
          Re: Implementing static_assert Keith Thompson <kst-u@mib.org> - 2015-05-07 09:11 -0700
            Re: Implementing static_assert James Kuyper <jameskuyper@verizon.net> - 2015-05-07 12:30 -0400
              Re: Implementing static_assert James Kuyper <jameskuyper@verizon.net> - 2015-05-07 12:55 -0400
      Re: Implementing static_assert Keith Thompson <kst-u@mib.org> - 2015-05-07 09:06 -0700
    Re: Implementing static_assert jacobnavia <jacob@jacob.remcomp.fr> - 2015-05-07 19:43 +0200
      Re: Implementing static_assert Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-07 16:10 -0700

Page 1 of 2  [1] 2  Next page →

#61640 — Implementing static_assert

I have added this useful construct to the lcc-win compiler.

Description:

#include <assert.h>
static_assert(boolean expression, message)

The boolean expression will be evaluated at compile time.

If the "boolean expression" is true at compile time, nothing happens,
the whole becomes a NOP (no operation).

If the boolean expression fails, the character string "message" will be
printed in an error message. The compiler appends the failed expression
to the message. The compilation fails and no object code is generated.

If the boolean expression can't be evaluated at compile time, the
compiler will generate a call to the _StaticAssert function, that will
print the error message at run time if the expression fails and exit the 
program.

What do you think?

Commentaries welcome.

[toc] | [next] | [standalone]

#61643

jacobnavia <jacob@jacob.remcomp.fr> writes:
> I have added this useful construct to the lcc-win compiler.
>
> Description:
>
> #include <assert.h>
> static_assert(boolean expression, message)
[snip]

See my reply in comp.compilers.lcc (I happened to see that first).

Quick summary: This is standard in C11.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#61644

Le 06/05/2015 22:28, Keith Thompson a écrit :
> jacobnavia <jacob@jacob.remcomp.fr> writes:
>> I have added this useful construct to the lcc-win compiler.
>>
>> Description:
>>
>> #include <assert.h>
>> static_assert(boolean expression, message)
> [snip]
>
> See my reply in comp.compilers.lcc (I happened to see that first).
>
> Quick summary: This is standard in C11.
>

Again, thanks a lot for this. A summary review of my implementation and 
the standard looks like they are the same...

I have just not understood what the static assertion in a structure 
declaration should do, but I have to read more carefully the stuff in 
the new C11 that I haven't really read that much.

Not specified is what to do when the expression is not a constant 
expression!

In my implementation I just call a run time procedure that will print 
the same error messages if the assert expression fails and return 
without doing anything if the assert expression is OK (different from zero).

Since the behavior of a non constant expression is not specified I 
suppose that this is OK. In a strict mode I will issue a warning.


What a surprise really. Yesterday I was looking at some C++ code and saw 
that construct and told me: "Interesting construct", and not that 
difficult to implement, so I did it today.

jacob

[toc] | [prev] | [next] | [standalone]

#61645

jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 06/05/2015 22:28, Keith Thompson a écrit :
>> jacobnavia <jacob@jacob.remcomp.fr> writes:
>>> I have added this useful construct to the lcc-win compiler.
>>>
>>> Description:
>>>
>>> #include <assert.h>
>>> static_assert(boolean expression, message)
>> [snip]
>>
>> See my reply in comp.compilers.lcc (I happened to see that first).
>>
>> Quick summary: This is standard in C11.
>>
>
> Again, thanks a lot for this. A summary review of my implementation
> and the standard looks like they are the same...
>
> I have just not understood what the static assertion in a structure
> declaration should do, but I have to read more carefully the stuff in
> the new C11 that I haven't really read that much.

I'm pretty sure having it inside a structure (or union) definition
doesn't affect anything.  It's just permitted in that context for
convenience.

> Not specified is what to do when the expression is not a constant
> expression!

The standard says "The constant expression shall be an integer constant
expression."  Since this is a "shall" outside a constraint, violating it
has undefined behavior.  (I find that a little surprising; I would think
it would make more sense for a non-constant expression to be a
constraint violation.)

One popular C compiler treats a non-constant expression as an error.
That would be my preference as well.  In C++, a non-constant expression
requires a diagnostic (if I'm reading the standard correctly).

> In my implementation I just call a run time procedure that will print
> the same error messages if the assert expression fails and return
> without doing anything if the assert expression is OK (different from
> zero).
>
> Since the behavior of a non constant expression is not specified I
> suppose that this is OK. In a strict mode I will issue a warning.
>
>
> What a surprise really. Yesterday I was looking at some C++ code and
> saw that construct and told me: "Interesting construct", and not that
> difficult to implement, so I did it today.

I think C11 may have borrowed static_assert from C++, with a change from
`static_assert` to `_Static_assert` to avoid breaking existing code.
One difference is that in C++ the message is optional.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#61647

On 5/6/2015 4:30 PM, Keith Thompson wrote:
> jacobnavia <jacob@jacob.remcomp.fr> writes:
>> Le 06/05/2015 22:28, Keith Thompson a écrit :
>>> jacobnavia <jacob@jacob.remcomp.fr> writes:
>>>> I have added this useful construct to the lcc-win compiler.

>>>> Description:

>>>> #include <assert.h>
>>>> static_assert(boolean expression, message)
>>> [snip]

>>> See my reply in comp.compilers.lcc (I happened to see that first).

>>> Quick summary: This is standard in C11.

>> Again, thanks a lot for this. A summary review of my implementation
>> and the standard looks like they are the same...

>> I have just not understood what the static assertion in a structure
>> declaration should do, but I have to read more carefully the stuff in
>> the new C11 that I haven't really read that much.

> I'm pretty sure having it inside a structure (or union) definition
> doesn't affect anything.  It's just permitted in that context for
> convenience.

>> Not specified is what to do when the expression is not a constant
>> expression!

> The standard says "The constant expression shall be an integer constant
> expression."  Since this is a "shall" outside a constraint, violating it
> has undefined behavior.  (I find that a little surprising; I would think
> it would make more sense for a non-constant expression to be a
> constraint violation.)

In the version I have (N1570), the constraint (6.7.10p2) reads, "The 
constant expression shall compare unequal to 0." Wouldn't that indicate 
a constraint violation for a non-constant expression?

> One popular C compiler treats a non-constant expression as an error.
> That would be my preference as well.  In C++, a non-constant expression
> requires a diagnostic (if I'm reading the standard correctly).

>> In my implementation I just call a run time procedure that will print
>> the same error messages if the assert expression fails and return
>> without doing anything if the assert expression is OK (different from
>> zero).

>> Since the behavior of a non constant expression is not specified I
>> suppose that this is OK. In a strict mode I will issue a warning.

>> What a surprise really. Yesterday I was looking at some C++ code and
>> saw that construct and told me: "Interesting construct", and not that
>> difficult to implement, so I did it today.

> I think C11 may have borrowed static_assert from C++, with a change from
> `static_assert` to `_Static_assert` to avoid breaking existing code.
> One difference is that in C++ the message is optional.

The message is not optional. N3797 says

Otherwise, the program is ill-formed, and the resulting diagnostic 
message (1.4) shall include the text of the string-literal, except that 
characters not in the basic source character set (2.3) are not required 
to appear in the diagnostic message.

Martin Shobe

[toc] | [prev] | [next] | [standalone]

#61651

Martin Shobe <martin.shobe@yahoo.com> writes:
> On 5/6/2015 4:30 PM, Keith Thompson wrote:
>> jacobnavia <jacob@jacob.remcomp.fr> writes:
[...]
>>> Not specified is what to do when the expression is not a constant
>>> expression!
>
>> The standard says "The constant expression shall be an integer constant
>> expression."  Since this is a "shall" outside a constraint, violating it
>> has undefined behavior.  (I find that a little surprising; I would think
>> it would make more sense for a non-constant expression to be a
>> constraint violation.)
>
> In the version I have (N1570), the constraint (6.7.10p2) reads, "The
> constant expression shall compare unequal to 0." Wouldn't that
> indicate a constraint violation for a non-constant expression?

Not directly, but a constraint violation is implied by the syntax.

The syntax is:

    static_assert-declaration:
        _Static_assert ( constant-expression , string-literal ) ;

A constant-expression is syntactically just a conditional-expression,
but the restrictions on constant-expressions are expressed as
constraints in N1570 6.6 p3-4.

I had missed that.  So using a non-constant expression in a
static_assert declaration *is* a constraint violation.

jacob, the required diagnostic can be a warning if you like, but it's
not optional if you want to follow the C11 definition, and I recommend
treating it as an error.

[...]

>> I think C11 may have borrowed static_assert from C++, with a change from
>> `static_assert` to `_Static_assert` to avoid breaking existing code.
>> One difference is that in C++ the message is optional.
>
> The message is not optional. N3797 says
>
> Otherwise, the program is ill-formed, and the resulting diagnostic
> message (1.4) shall include the text of the string-literal, except
> that characters not in the basic source character set (2.3) are not
> required to appear in the diagnostic message.

So it does -- but N4296 gives the syntax as:

    static_assert-declaration:
        static_assert ( constant-expression ) ;
        static_assert ( constant-expression , string-literal ) ;

and says:

    Otherwise, the program is ill-formed, and the resulting diagnostic
    message (1.4) shall include the text of the string-literal, if one
    is supplied, except that characters not in the basic source
    character set (2.3) are not required to appear in the diagnostic
    message.

Since they made the string-literal optional, I'm a little surprised they
didn't require the message to include the text of the expression if the
string-literal is missing, as is already done for assert() (which takes
only an expression).

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#61669

On 07/05/15 01:07, Martin Shobe wrote:
> On 5/6/2015 4:30 PM, Keith Thompson wrote:
>> jacobnavia <jacob@jacob.remcomp.fr> writes:

>> I think C11 may have borrowed static_assert from C++, with a change from
>> `static_assert` to `_Static_assert` to avoid breaking existing code.

C++ introduced static_assert in C++11, so the two languages got the
feature at roughly the same time, rather than one copying directly from
the other.

>> One difference is that in C++ the message is optional.
> 
> The message is not optional. N3797 says
> 
> Otherwise, the program is ill-formed, and the resulting diagnostic
> message (1.4) shall include the text of the string-literal, except that
> characters not in the basic source character set (2.3) are not required
> to appear in the diagnostic message.
> 

IIRC the message will be optional in C++17, according to current plan.

[toc] | [prev] | [next] | [standalone]

#61717

jacobnavia <jacob@jacob.remcomp.fr> writes:

> Le 06/05/2015 22:28, Keith Thompson a ecrit :
>> jacobnavia <jacob@jacob.remcomp.fr> writes:
>>> I have added this useful construct to the lcc-win compiler.
>>>
>>> Description:
>>>
>>> #include <assert.h>
>>> static_assert(boolean expression, message)
>>
>> [snip]
>>
>> See my reply in comp.compilers.lcc (I happened to see that first).
>>
>> Quick summary:  This is standard in C11.
>
> Again, thanks a lot for this.  A summary review of my implementation
> and the standard looks like they are the same...
>
> I have just not understood what the static assertion in a structure
> declaration should do, but I have to read more carefully the stuff in
> the new C11 that I haven't really read that much.
>
> Not specified is what to do when the expression is not a constant
> expression!
>
> In my implementation I just call a run time procedure that will print
> the same error messages if the assert expression fails and return
> without doing anything if the assert expression is OK (different from
> zero).
>
> Since the behavior of a non constant expression is not specified I
> suppose that this is OK.  In a strict mode I will issue a warning.

Some miscellaneous comments.

If your compiler has option settings to choose which version
of the standard to conform to (ie, C90, C99, or C11) then 
'static_assert' should be defined only in the C11 mode.

In any case, whenever static_assert is defined it should match
the description given in C11, ie, as a regular (non-function)
macro that expands to _Static_assert.  AFAIK there is no problem
in having _Static_assert available in all choices of which
version of the standard is being used.  Incidentally I think
this goes without saying but I will say it anyway, that the
behavior of _Static_assert (and so of static_assert) should
match faithfully what C11 describes for it.

A _Static_assert in a struct definition simply tests the
condition in the same way it would in other contexts.  It
has no effect on the struct being defined.

If a static assert is given whose condition is not a constant
expression, that is a constraint violation and must be given
a diagnostic.  FWIW, I think it's okay to give a warning
rather than an error, as long as there is an option to force
it being an error (which is probably a good default setting,
in which case presumably there would be an option for a
warning rather than an error).  Also FWIW I think it's okay
in the "warning" case to test the conditions at run-time,
with similar remarks about options and defaults.  A question
though:  what do you do about static_assert's that appear
outside of any function body?

Fine point:  a _Static_assert requires a constant expression, but
the specification of that being an integer constant expression is
simply a 'shall', not a constraint.  This observation is relevant
because implementations are allowed to accept other forms of
constant expressions, so such other forms would not require any
diagnostic message.  (A constant expression not being unequal to
0 would still require a diagnostic message.)  I'm not suggesting
doing this is a good idea (or a bad idea), just pointing it out
for completeness.

[toc] | [prev] | [next] | [standalone]

#61671

On 06/05/15 21:44, jacobnavia wrote:
> I have added this useful construct to the lcc-win compiler.
> 
> Description:
> 
> #include <assert.h>
> static_assert(boolean expression, message)
> 
> The boolean expression will be evaluated at compile time.
> 
> If the "boolean expression" is true at compile time, nothing happens,
> the whole becomes a NOP (no operation).
> 
> If the boolean expression fails, the character string "message" will be
> printed in an error message. The compiler appends the failed expression
> to the message. The compilation fails and no object code is generated.
> 
> If the boolean expression can't be evaluated at compile time, the
> compiler will generate a call to the _StaticAssert function, that will
> print the error message at run time if the expression fails and exit the
> program.

I /strongly/ disapprove of the idea of turning the static assert into a
run-time call if it can't be evaluated at compile-time.  I am not as
experienced a "language lawyer" as Keith and some of the others here,
but I believe the C11 standards insist that the boolean expression be
compile-time constant - and I certainly think that /should/ be the case.
 It is in the name - it is a /static/ assertion, and should have a
/static/ effect.  So no matter what freedom the C11 standard may or may
not give, give an error message if the expression is not constant.

Conversely, I would consider turning an "old-fashioned" assert into a
static assertion if the expression is compile-time constant.

> 
> What do you think?
> 
> Commentaries welcome.
> 
> 
> 

[toc] | [prev] | [next] | [standalone]

#61675

David Brown wrote:
> On 06/05/15 21:44, jacobnavia wrote:
>> I have added this useful construct to the lcc-win compiler.
>>
>> Description:
>>
>> #include <assert.h>
>> static_assert(boolean expression, message)
>>
>> The boolean expression will be evaluated at compile time.
>>
>> If the "boolean expression" is true at compile time, nothing happens,
>> the whole becomes a NOP (no operation).
>>
>> If the boolean expression fails, the character string "message" will be
>> printed in an error message. The compiler appends the failed expression
>> to the message. The compilation fails and no object code is generated.
>>
>> If the boolean expression can't be evaluated at compile time, the
>> compiler will generate a call to the _StaticAssert function, that will
>> print the error message at run time if the expression fails and exit the
>> program.
>
> I /strongly/ disapprove of the idea of turning the static assert into a
> run-time call if it can't be evaluated at compile-time.  I am not as
> experienced a "language lawyer" as Keith and some of the others here,
> but I believe the C11 standards insist that the boolean expression be
> compile-time constant - and I certainly think that /should/ be the case.
>   It is in the name - it is a /static/ assertion, and should have a
> /static/ effect.  So no matter what freedom the C11 standard may or may
> not give, give an error message if the expression is not constant.

I completely agree.  If the programmer doesn't realise the expression 
can't be evaluated at compile time, they could be lulled into a false 
sense of security.  A static_assert should fail a compile time, it is 
likely to be used to check the sanity of a build environment.  One 
example would be a continuous integration build that is built but never run.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#61676

Le 07/05/2015 12:13, Ian Collins a écrit :
> David Brown wrote:
>> On 06/05/15 21:44, jacobnavia wrote:
>>> I have added this useful construct to the lcc-win compiler.
>>>
>>> Description:
>>>
>>> #include <assert.h>
>>> static_assert(boolean expression, message)
>>>
>>> The boolean expression will be evaluated at compile time.
>>>
>>> If the "boolean expression" is true at compile time, nothing happens,
>>> the whole becomes a NOP (no operation).
>>>
>>> If the boolean expression fails, the character string "message" will be
>>> printed in an error message. The compiler appends the failed expression
>>> to the message. The compilation fails and no object code is generated.
>>>
>>> If the boolean expression can't be evaluated at compile time, the
>>> compiler will generate a call to the _StaticAssert function, that will
>>> print the error message at run time if the expression fails and exit the
>>> program.
>>
>> I /strongly/ disapprove of the idea of turning the static assert into a
>> run-time call if it can't be evaluated at compile-time.  I am not as
>> experienced a "language lawyer" as Keith and some of the others here,
>> but I believe the C11 standards insist that the boolean expression be
>> compile-time constant - and I certainly think that /should/ be the case.
>>   It is in the name - it is a /static/ assertion, and should have a
>> /static/ effect.  So no matter what freedom the C11 standard may or may
>> not give, give an error message if the expression is not constant.
>
> I completely agree.  If the programmer doesn't realise the expression
> can't be evaluated at compile time, they could be lulled into a false
> sense of security.  A static_assert should fail a compile time, it is
> likely to be used to check the sanity of a build environment.  One
> example would be a continuous integration build that is built but never
> run.
>

1: If the expression fails at compile time an error is issued and 
compilation fails.

2: If the expression is not a constant expression, code is generated to 
evaluate it at run time. The objective of that was to replace assert by 
static assert, and (if possible) test all the asserts at compile time to 
produce an error message at compile time if possible.

For instance

assert(sizeof(void *) == 4)

would be tested at run time even if it could be done at compile time.

But aparently everyone agrees that that is an error...

[toc] | [prev] | [next] | [standalone]

#61678

jacobnavia wrote:
> Le 07/05/2015 12:13, Ian Collins a écrit :
>> David Brown wrote:
>>>
>>> I /strongly/ disapprove of the idea of turning the static assert into a
>>> run-time call if it can't be evaluated at compile-time.  I am not as
>>> experienced a "language lawyer" as Keith and some of the others here,
>>> but I believe the C11 standards insist that the boolean expression be
>>> compile-time constant - and I certainly think that /should/ be the case.
>>>    It is in the name - it is a /static/ assertion, and should have a
>>> /static/ effect.  So no matter what freedom the C11 standard may or may
>>> not give, give an error message if the expression is not constant.
>>
>> I completely agree.  If the programmer doesn't realise the expression
>> can't be evaluated at compile time, they could be lulled into a false
>> sense of security.  A static_assert should fail a compile time, it is
>> likely to be used to check the sanity of a build environment.  One
>> example would be a continuous integration build that is built but never
>> run.
>>
>
> 1: If the expression fails at compile time an error is issued and
> compilation fails.
>
> 2: If the expression is not a constant expression, code is generated to
> evaluate it at run time. The objective of that was to replace assert by
> static assert, and (if possible) test all the asserts at compile time to
> produce an error message at compile time if possible.
>
> For instance
>
> assert(sizeof(void *) == 4)
>
> would be tested at run time even if it could be done at compile time.
>
> But aparently everyone agrees that that is an error...

It isn't an error, it is what assert does.

What static_assert does is completely different, this is a good example 
of a use case for static_assert.  As David mentions, it would make sense 
for asserts of compile time constants to be evaluated at compile time, 
not the other way.

If I write a static_assert in my code, I want it to fail to build if the 
condition isn't met.  As part of out continuous integration process, I 
build out embedded targets with the ARM-gcc tool chain as part of each 
build.  These builds are never run, so a static_assert that doesn't do 
what is says on the tin is worse than useless.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#61680

On 07/05/15 12:33, Ian Collins wrote:
> jacobnavia wrote:
>> Le 07/05/2015 12:13, Ian Collins a écrit :
>>> David Brown wrote:
>>>>
>>>> I /strongly/ disapprove of the idea of turning the static assert into a
>>>> run-time call if it can't be evaluated at compile-time.  I am not as
>>>> experienced a "language lawyer" as Keith and some of the others here,
>>>> but I believe the C11 standards insist that the boolean expression be
>>>> compile-time constant - and I certainly think that /should/ be the
>>>> case.
>>>>    It is in the name - it is a /static/ assertion, and should have a
>>>> /static/ effect.  So no matter what freedom the C11 standard may or may
>>>> not give, give an error message if the expression is not constant.
>>>
>>> I completely agree.  If the programmer doesn't realise the expression
>>> can't be evaluated at compile time, they could be lulled into a false
>>> sense of security.  A static_assert should fail a compile time, it is
>>> likely to be used to check the sanity of a build environment.  One
>>> example would be a continuous integration build that is built but never
>>> run.
>>>
>>
>> 1: If the expression fails at compile time an error is issued and
>> compilation fails.
>>
>> 2: If the expression is not a constant expression, code is generated to
>> evaluate it at run time. The objective of that was to replace assert by
>> static assert, and (if possible) test all the asserts at compile time to
>> produce an error message at compile time if possible.
>>
>> For instance
>>
>> assert(sizeof(void *) == 4)
>>
>> would be tested at run time even if it could be done at compile time.
>>
>> But aparently everyone agrees that that is an error...
> 
> It isn't an error, it is what assert does.
> 
> What static_assert does is completely different, this is a good example
> of a use case for static_assert.  As David mentions, it would make sense
> for asserts of compile time constants to be evaluated at compile time,
> not the other way.
> 
> If I write a static_assert in my code, I want it to fail to build if the
> condition isn't met.  As part of out continuous integration process, I
> build out embedded targets with the ARM-gcc tool chain as part of each
> build.  These builds are never run, so a static_assert that doesn't do
> what is says on the tin is worse than useless.
> 

Exactly.  The kinds of things I use static_assert for include checking
the sizes of structures that must match external data or hardware, or
checking that expressions using compile-time defined constants fit
within the constraints of the types I'm using, or that assumptions I
make to simplify or optimise code are consistent throughout a program.
The only reason these might not be compile-time constant expressions is
if I've made a mistake in the expression - and I want that to be an
error message!

In addition, most of my systems have no concept of "printing an error
message" at run-time, or even of "exiting the program".  I realise this
is not the sort of system that lcc-win targets, but I would expect no
less of a compiler for Windows software.  Catching errors quickly at
compile time is a major reason to choose C or C++ over something like
Python when working on a PC.

[toc] | [prev] | [next] | [standalone]

#61679

David Brown wrote:
> Conversely, I would consider turning an "old-fashioned" assert into a
> static assertion if the expression is compile-time constant.

No, you can't do that--even if the expression in an assert is a compile-
time constant, the program can't abort unless/until it is executed. 
Consider:


void a()
{
    assert(sizeof (void *) == 4);
    // handle special case
}

void b()
{
    // handle general case
}

int main()
{
    if (sizeof (void *) == 4)
        a();
    else
        b();

    return 0;
}

[toc] | [prev] | [next] | [standalone]

#61681

On 07/05/15 12:53, Philip Lantz wrote:
> David Brown wrote:
>> Conversely, I would consider turning an "old-fashioned" assert into a
>> static assertion if the expression is compile-time constant.
> 
> No, you can't do that--even if the expression in an assert is a compile-
> time constant, the program can't abort unless/until it is executed. 
> Consider:
> 
> 
> void a()
> {
>     assert(sizeof (void *) == 4);
>     // handle special case
> }
> 
> void b()
> {
>     // handle general case
> }
> 
> int main()
> {
>     if (sizeof (void *) == 4)
>         a();
>     else
>         b();
> 
>     return 0;
> }
> 

That's why I said I would /consider/ doing this - I realise there are
cases where you might want to avoid a compile-time error here.  I
suspect that in many such cases you could re-arrange things to avoid
this problem (perhaps by realising omitting the assert altogether, when
you know it must be true).  It should also often be possible for the
compiler to realise that the assert is either never run, in which case
no error is needed, or it /is/ run and it is always true (in which case
the assert itself can be omitted).

But certainly it is not something one could change easily without
breaking existing code.

[toc] | [prev] | [next] | [standalone]

#61691

David Brown <david.brown@hesbynett.no> writes:
> On 07/05/15 12:53, Philip Lantz wrote:
>> David Brown wrote:
>>> Conversely, I would consider turning an "old-fashioned" assert into a
>>> static assertion if the expression is compile-time constant.
>> 
>> No, you can't do that--even if the expression in an assert is a compile-
>> time constant, the program can't abort unless/until it is executed. 
[...]

> That's why I said I would /consider/ doing this - I realise there are
> cases where you might want to avoid a compile-time error here.

Yes -- and those cases are *all uses of assert()*.

> But certainly it is not something one could change easily without
> breaking existing code.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#61694

On 05/07/2015 12:11 PM, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 07/05/15 12:53, Philip Lantz wrote:
>>> David Brown wrote:
>>>> Conversely, I would consider turning an "old-fashioned" assert into a
>>>> static assertion if the expression is compile-time constant.
>>>
>>> No, you can't do that--even if the expression in an assert is a compile-
>>> time constant, the program can't abort unless/until it is executed. 
> [...]
> 
>> That's why I said I would /consider/ doing this - I realise there are
>> cases where you might want to avoid a compile-time error here.
> 
> Yes -- and those cases are *all uses of assert()*.

I don't think so. I've frequently seen assert() used in cases where
_Static_assert() would have been preferred, but was not used because it
wasn't available yet. I think that this may be true of many, and perhaps
most, of the assert()s where the argument is a compile-time constant.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#61695

On 05/07/2015 12:30 PM, James Kuyper wrote:
> On 05/07/2015 12:11 PM, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 07/05/15 12:53, Philip Lantz wrote:
>>>> David Brown wrote:
>>>>> Conversely, I would consider turning an "old-fashioned" assert into a
>>>>> static assertion if the expression is compile-time constant.
>>>>
>>>> No, you can't do that--even if the expression in an assert is a compile-
>>>> time constant, the program can't abort unless/until it is executed. 
>> [...]
>>
>>> That's why I said I would /consider/ doing this - I realise there are
>>> cases where you might want to avoid a compile-time error here.
>>
>> Yes -- and those cases are *all uses of assert()*.
> 
> I don't think so. I've frequently seen assert() used in cases where
> _Static_assert() would have been preferred, but was not used because it
> wasn't available yet. I think that this may be true of many, and perhaps
> most, of the assert()s where the argument is a compile-time constant.

Having seen one of your other posts on this thread, I want to partially
retract that statement. Because assert(0) is often used to identify
blocks of code that should never be entered, drop the ", and perhaps
most," from the above statement.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#61690

David Brown <david.brown@hesbynett.no> writes:
[...]
> Conversely, I would consider turning an "old-fashioned" assert into a
> static assertion if the expression is compile-time constant.

"Old-fashioned" asserts are handled at run time.

This program:

    #include <assert.h>
    int main(void) {
        assert(0);
    }

has (mostly) well-defined behavior.  It's not strictly conforming
because the message is implementation-defined, but a compiler
should not reject it.  (I'm ignoring non-standard compiler options
like -DNDEBUG.)

And of course you can have code like:

    if (something_bad_happened) {
        assert(0);
    }

Of course a compiler can print a compile-time warning, and it would
be sensible to do so.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#61700

Le 06/05/2015 21:44, jacobnavia a écrit :
> I have added this useful construct to the lcc-win compiler.
>
> Description:
>
> #include <assert.h>
> static_assert(boolean expression, message)
>
> The boolean expression will be evaluated at compile time.
>
> If the "boolean expression" is true at compile time, nothing happens,
> the whole becomes a NOP (no operation).
>
> If the boolean expression fails, the character string "message" will be
> printed in an error message. The compiler appends the failed expression
> to the message. The compilation fails and no object code is generated.
>
> If the boolean expression can't be evaluated at compile time, the
> compiler will generate a call to the _StaticAssert function, that will
> print the error message at run time if the expression fails and exit the
> program.
>
> What do you think?
>
> Commentaries welcome.
>
>
>

Due to popular demand, the opton of a run time error for a static assert 
has been dropped.

:-(

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web