Re: [avr-gcc-list] Can enumerator values be used in a #if preprocessordirective?
Refinements of the concept left as an exercise for the reader. Regards, Does that mean I am not allowed to post my refinements? No. Please post. Extra points for using __FILE__ __FUNCITON__ and __LINE__ to give meaningful error message. Digging out my old issue of Embedded Systems on Compile Time Assertions we find this: http://www.eetimes.com/discussion/programming-pointers/4025549/Catching-errors-early-with-compile-time-assertions One thing to watch out for in some of the examples I've seen is in C99 a zero length variable array could be created. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Can enumerator values be used in a #if preprocessordirective?
On 30/08/2011 14:03, Bob Paddock wrote:
Refinements of the concept left as an exercise for the reader. Regards,
Does that mean I am not allowed to post my refinements?
No. Please post. Extra points for using __FILE__ __FUNCITON__ and
__LINE__ to give meaningful error message.
The error message already contains information about the line number,
just like for any other error message.
You can't get very meaningful errors here - I have not found any way to
get a user-defined error message in conjunction with static asserts.
There is, AFAIK, an effort to get standardised static assertions into
both C and C++ with useful messages. But in a fine example of
mind-blowing stupidity, C++0x uses
static_assert(expression, message)
while C1x calls it _Static_assert.
If your compiler supports static_assert or _Static_assert (gcc 4.6
onwards) then you are best using it directly.
Digging out my old issue of Embedded Systems on Compile Time Assertions
we find this:
http://www.eetimes.com/discussion/programming-pointers/4025549/Catching-errors-early-with-compile-time-assertions
One thing to watch out for in some of the examples I've seen is in C99
a zero length variable array could be created.
My macros (message is for compatibility with future C/C++ standards, and
self-documentation of the code - it is not used by the macro):
#define STATIC_ASSERT_NAME_(line) STATIC_ASSERT_NAME2_(line)
#define STATIC_ASSERT_NAME2_(line) assertion_failed_at_line_##line
#define static_assert(claim, message) \
typedef struct { \
char STATIC_ASSERT_NAME_(__LINE__) [(claim) ? 1 : -1]; \
} STATIC_ASSERT_NAME_(__LINE__)
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Can enumerator values be used in a #if preprocessordirective?
You can't get very meaningful errors here - I have not found any way to get a user-defined error message in conjunction with static asserts. I added ##_##message, to NAME2_ and updated everything else as needed, so now I get static_assert( 1 == 2, One_Not_Equal_To_Two ); that looks like: assertion_failed_at_line_767_One_Not_Equal_To_Two Closer to a meaningful message at least. AFAIK, an effort to get standardised static assertions into both C and C++ with useful messages. But in a fine example of mind-blowing stupidity, C++0x uses static_assert(expression, message) while C1x calls it _Static_assert. Standards are great thing, everyone can have one. :-( Thank you and everyone else for the help. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Can enumerator values be used in a #if preprocessordirective?
Hi Bob,
The preprocessor runs, of course, before the compiler.
So you're trying to check if an enum is greater than some value, when the
compiler phase hasn't even evaluated the enum list and assigned values to
last.
For the preprocessor purposes, I would bet that somehow last evaluates to 0,
so of course the condition will always be true.
You might have to change the conditional compilation to some sort of assert.
Eric
-Original Message-
From: avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org
[mailto:avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org] On
Behalf Of Bob Paddock
Sent: Monday, August 29, 2011 12:37 PM
To: AVR-GCC
Subject: [avr-gcc-list] Can enumerator values be used in a #if
preprocessordirective?
I have the following file test.c:
#define MAX (2U)
enum ENUM_EXAMPLE{ a, b, c, d, e, last };
#if( last = MAX )
#error Last is greater than MAX.
#endif
/*
* Never get as far as this main when compiling with other code to mater,
* need for the standalone test:
*/
int main( void )
{
}
If I do 'avr-gcc test.c' I get an a.out file and no errors.
If I include test.c in my project I get 'error: last is not defined'.
Why would it be defined in the standalone one and not defined in the
other?
Looking in C: A Reference Manual 5th edition by Harbison and Steele they
make the distinction between preprocessor constant expressions and
integral constant expressions in section 7.11/7.11.1. In 7.11.1
enums are not listed as a allowable type to #if. If that is the case
why does the standalone compile of test.c compile? If that is not the
case why is 'last' not defined?
I'm confused by this inconstancy, what am I overlooking here?
The goal in my real code is to know when I've assigned more than 254
enums in one enumerator set.
Is there a different way to do this?
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Can enumerator values be used in a #if preprocessordirective?
On Mon, 29 Aug 2011, Weddington, Eric wrote: For the preprocessor purposes, I would bet that somehow last evaluates to 0, so of course the condition will always be true. Yes, I think this is part of the language standard (for better or worse). I don't have a standard cite but it's described in the GNU docs: http://gcc.gnu.org/onlinedocs/gcc-3.0.1/cpp_4.html#SEC38 [6] Identifiers that are not macros, which are all considered to be the number zero. [] ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Can enumerator values be used in a #if preprocessordirective?
On Mon, Aug 29, 2011 at 3:15 PM, Wim Lewis w...@.org wrote: On Mon, 29 Aug 2011, Weddington, Eric wrote: For the preprocessor purposes, I would bet that somehow last evaluates to 0, so of course the condition will always be true. [6] Identifiers that are not macros, which are all considered to be the number zero. [] Adding -Wundef to avr-gcc test.c now gets the same error. I already had that in my project Makefile along with all the other warnings. So that explains the difference. Seems like there could be a better error message for this case, 'don't use enum here', alas The preprocessor does not know anything about types in the language... Thank you. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Can enumerator values be used in a #if preprocessordirective?
From: graceindustr...@gmail.com
[...]
So that explains the difference. Seems like there could be a better
error message for this case, 'don't use enum here', alas The
preprocessor does not know anything about types in the language...
Here's a cute/ugly little macro that might help you find the errors you're
looking for:
#define ctassert(n,e) extern unsigned char n[(e)?0:-1]
Here's an example of how you might use it:
enum{a,b,c,d,last};
#define MAX 2
ctassert(big_enough,(last = MAX));
Note that the macro does not need to be invoked from within a function. If the
test fails, the error message is almost pretty good, depending on what you
choose for the array name (sztest.c:6: error: size of array `big_enough' is
negative).
Refinements of the concept left as an exercise for the reader. Regards,
-=Dave
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
