Bug 39462 - check assert() at compile time if possible
Summary: check assert() at compile time if possible
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: unknown
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-14 17:17 UTC by Albert Zeyer
Modified: 2012-01-08 21:51 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Albert Zeyer 2009-03-14 17:17:55 UTC
I have a lot of cases where it would be possible (more or less trivial, depending on the situation/code) to check if an assert() would fail at compile time. In such cases, I would want that GCC gives a warning (or an error).

I understand that it's not possible to catch all cases but on such cases where it is easy for GCC to do such a check, I would like that GCC does it and reports it if it would fail.

For the warning itself: The warning should point out the line where the problem is really caused (or all lines which could cause that problem). E.g., if I have an inline function where the assert depends on the function argument, I would like to get the line-nr where I call that function, not the line-nr of the assert() itself.

(Just to avoid confusion: I am aware of static asserts but these are different things and not an option in most cases where I use assert(). Also, I don't want to make things harder for myself to figure out always when I can use an static assert and when not. And anyway, there are still a lot of trivial cases where a static assert is not possible but it would be still trivial for the compiler to see that it would fail.)
Comment 1 Richard Biener 2009-03-14 17:33:12 UTC
You should be able to do this already with something like

void do_the_warning (void) __attribute__((warning("assertion always false")));

#define assert(X) \
if (__builtin_constant_p (X) \
    && !(X))                  \
  do_the_warning ();          \
if (!(X)) abort ();
Comment 2 Albert Zeyer 2009-03-14 19:48:31 UTC
Really thanks a lot for that hint.

I did a small assert-implementation by my own:
http://openlierox.svn.sourceforge.net/viewvc/openlierox/include/cassert?view=markup

Btw., it seems that Apples GCC (even 4.2) does not support that attribute. Any alternative? But I guess you (GCC devs) are not responsible for that.
Comment 3 Richard Biener 2009-03-14 20:25:10 UTC
The attribute is new in GCC 4.3.
Comment 4 Paolo Carlini 2009-03-14 23:41:15 UTC
Also - I admit not having studied in detail all your requirements, sorry about that - I suppose you would be interested in static_assert, available with -std=c++0x, in gcc4.3.x (and 4.4.x, of course):

  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1720.html
Comment 5 Albert Zeyer 2009-03-15 00:10:37 UTC
(In reply to comment #4)
> Also - I admit not having studied in detail all your requirements, sorry about
> that - I suppose you would be interested in static_assert, available with
> -std=c++0x, in gcc4.3.x (and 4.4.x, of course):
> 
>   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1720.html
> 

Thanks, but static_assert is not an option. It would make things only more complicated and can not cover a lot of cases.

I also don't really understand why there is something like a static_assert (I am not sure how much I really would use an assert outside of a function). If a compiler would be intelligent enough to check asserts at compile time if possible, to differ between static_assert and assert only makes it more complicated - mostly for the programmer.
Comment 6 Paolo Carlini 2009-03-15 00:31:56 UTC
Hey, no problem really, just wanted to let you aware that the next Standard will deliver an assert checked at compile time. In general, if you want something special for the next releases of the C++ Standard, I would suggest making sure people in the appropriate places hear your voice. In general, we (GCC Project) are mostly interested in features already standardized or designed with that in mind.
Comment 7 Albert Zeyer 2009-03-15 00:58:55 UTC
Hm yea, I thought already about that. But I cannot think of a good (and easy) definition when an assert() should be checked at compile time and whether not. And thus, I am not sure if that is something which belongs into the C++ standard itself.

That is why I thought it would be the best to let the compiler do such a check if possible (and that pretty much depends on the cleverness of the compiler) and to just accept the situation that there could be cases where the value could be known in theory already at compile time but the compiler doesn't catch that.

static asserts are different again (and I don't think there are of no use). There is a common intersection between what I want and what static asserts would offer but this intersection is small and they will not really solve the issue that it would be still very nice if the compiler could check asserts at compile time if possible (and in that case, I think that static asserts are only of little use; but it's of course hard to tell that, also because if not all compiler supports compile-time checks on asserts, a lot of people will use static asserts as a semi-alternative).

But I could also just be wrong with these thoughts. I am not really into the GCC development and even after about 5 years of C++ development, I still see more and more new and different ways of doing stuff in C++.
Comment 8 Paolo Carlini 2011-09-29 00:00:28 UTC
I guess we can as well close this.
Comment 9 Andrew Pinski 2012-01-08 21:51:17 UTC
(In reply to comment #4)
> Also - I admit not having studied in detail all your requirements, sorry about
> that - I suppose you would be interested in static_assert, available with
> -std=c++0x, in gcc4.3.x (and 4.4.x, of course):
> 
>   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1720.html

And static assert is now part of C11 standard. And can be used in 4.7 and above with _Static_assert keyword.