For example, how can I get rid of "warning: unnamed struct/union that defines no instances" in the source file, not through compiler command-line options.
I want to define a C macro CONST_BUG_ON, which I use to check some const values at compile time.
#define CONST_BUG_ON(e) struct {int a:!(e);}
It gives the warning warning: unnamed struct/union that defines no instances, but in this case it is not a real problem.
Thanks Tom Tanner
#define CONST_BUG_ON_3(e, l) struct buggy##l {int a:!(e);}
#define CONST_BUG_ON_2(e, l) CONST_BUG_ON_3(e, l)
#define CONST_BUG_ON(e) CONST_BUG_ON_2(e, __LINE__)
That's good, but still have some problems: If file a's line 6 contain CONST_BUG_ON(e), and file a was inclued by file b, and line 6 of file b aslo contains CONST_BUG_ON(e), then gcc complains redefine error. Use__COUNTER__ instade of __LINE__ may perfect, but my old compiler does not support __COUNTER__.
Thanks Basile Starynkevitch
#define CONST_BUG_ON(e) do { \
int tab[__builtin_constant_p(e)?1:-1] = {0}; \
if (tab[0]) abort(); } while (0)
This is a C statement, can only be place in a function, I really want to use it outside the function.
One way to resolve the compiler’s complaint is that you have an unnamed struct that defines no instances is to give it a name:
#define CONST_BUG_ON(e) struct ForDebuggingOnly {int a:!(e);}
An alternate way to get the expression testing you want is to declare (but not define) an array that has an illegal size if e is true:
#define CONST_BUG_ON(e) extern int ForDebuggingOnly[(e) ? -1 : 1]
You could use macro magic to give yourself a unique ID by passing in the line number
#define CONST_BUG_ON_3(e, l) struct buggy##l {int a:!(e);}
#define CONST_BUG_ON_2(e, l) CONST_BUG_ON_3(e, l)
#define CONST_BUG_ON(e) CONST_BUG_ON_2(e, __LINE__)
That's fairly icky but it does give a unique name each time it is used (the 2nd level of indirection may be spurious, but this is what I have in some code that has stood the test of time).
It looks like what you try is called a compile time assertion or compile time assert macro. There are various ways to do this, usually involving arrays with negative dimension when the assertion fails. Many projects call this macro CT_ASSERT() and there are a bunch of Stackoverflow questions relating to them.
Assuming a recent GCC compiler, you could use __builtin_constant_p to test for compile-time constants, perhaps with
#define CONST_BUG_ON(e) do { \
int tab[__builtin_constant_p(e)?1:-1] = {0}; \
if (tab[0]) abort(); } while (0)
For your question about ignoring some warning, perhaps the GCC diagnostic pragmas could help.
If you want your CONST_BUG_ON to work only in declaration contexts, you might try
#define CONST_BUG_ON(e) CONST_BUG_AT(e,__LINE__)
#define CONST_BUG_AT(e,l) \
extern int tab_##l[__builtin_constant_p(e)?0:-1];
At last you could even customize your GCC compiler (with your specific pragma) perhaps using MELT (a high-level domain specific language to extend GCC), but that will take you days of work.
Related
I'd like to implement an "assert" that prevents compilation, rather than failing at runtime, in the error case.
I currently have one defined like this, which works great, but which increases the size of the binaries.
#define MY_COMPILER_ASSERT(EXPRESSION) switch (0) {case 0: case (EXPRESSION):;}
Sample code (which fails to compile).
#define DEFINE_A 1
#define DEFINE_B 1
MY_COMPILER_ASSERT(DEFINE_A == DEFINE_B);
How can I implement this so that it does not generate any code (in order to minimize the size of the binaries generated)?
A compile-time assert in pure standard C is possible, and a little bit of preprocessor trickery makes its usage look just as clean as the runtime usage of assert().
The key trick is to find a construct that can be evaluated at compile time and can cause an error for some values. One answer is the declaration of an array cannot have a negative size. Using a typedef prevents the allocation of space on success, and preserves the error on failure.
The error message itself will cryptically refer to declaration of a negative size (GCC says "size of array foo is negative"), so you should pick a name for the array type that hints that this error really is an assertion check.
A further issue to handle is that it is only possible to typedef a particular type name once in any compilation unit. So, the macro has to arrange for each usage to get a unique type name to declare.
My usual solution has been to require that the macro have two parameters. The first is the condition to assert is true, and the second is part of the type name declared behind the scenes. The answer by plinth hints at using token pasting and the __LINE__ predefined macro to form a unique name possibly without needing an extra argument.
Unfortunately, if the assertion check is in an included file, it can still collide with a check at the same line number in a second included file, or at that line number in the main source file. We could paper over that by using the macro __FILE__, but it is defined to be a string constant and there is no preprocessor trick that can turn a string constant back into part of an identifier name; not to mention that legal file names can contain characters that are not legal parts of an identifier.
So, I would propose the following code fragment:
/** A compile time assertion check.
*
* Validate at compile time that the predicate is true without
* generating code. This can be used at any point in a source file
* where typedef is legal.
*
* On success, compilation proceeds normally.
*
* On failure, attempts to typedef an array type of negative size. The
* offending line will look like
* typedef assertion_failed_file_h_42[-1]
* where file is the content of the second parameter which should
* typically be related in some obvious way to the containing file
* name, 42 is the line number in the file on which the assertion
* appears, and -1 is the result of a calculation based on the
* predicate failing.
*
* \param predicate The predicate to test. It must evaluate to
* something that can be coerced to a normal C boolean.
*
* \param file A sequence of legal identifier characters that should
* uniquely identify the source file in which this condition appears.
*/
#define CASSERT(predicate, file) _impl_CASSERT_LINE(predicate,__LINE__,file)
#define _impl_PASTE(a,b) a##b
#define _impl_CASSERT_LINE(predicate, line, file) \
typedef char _impl_PASTE(assertion_failed_##file##_,line)[2*!!(predicate)-1];
A typical usage might be something like:
#include "CAssert.h"
...
struct foo {
... /* 76 bytes of members */
};
CASSERT(sizeof(struct foo) == 76, demo_c);
In GCC, an assertion failure would look like:
$ gcc -c demo.c
demo.c:32: error: size of array `assertion_failed_demo_c_32' is negative
$
The following COMPILER_VERIFY(exp) macro works fairly well.
// combine arguments (after expanding arguments)
#define GLUE(a,b) __GLUE(a,b)
#define __GLUE(a,b) a ## b
#define CVERIFY(expr, msg) typedef char GLUE (compiler_verify_, msg) [(expr) ? (+1) : (-1)]
#define COMPILER_VERIFY(exp) CVERIFY (exp, __LINE__)
It works for both C and C++ and can be used anywhere a typedef would be allowed. If the expression is true, it generates a typedef for an array of 1 char (which is harmless). If the expression is false, it generates a typedef for an array of -1 chars, which will generally result in an error message. The expression given as an arugment can be anything that evaluates to a compile-time constant (so expressions involving sizeof() work fine). This makes it much more flexible than
#if (expr)
#error
#endif
where you are restricted to expressions that can be evaluated by the preprocessor.
As Leander said, static assertions are being added to C++11, and now they have.
static_assert(exp, message)
For example
#include "myfile.hpp"
static_assert(sizeof(MyClass) == 16, "MyClass is not 16 bytes!")
void doStuff(MyClass object) { }
See the cppreference page on it.
The best writeup that I could find on static assertions in C is at pixelbeat. Note that static assertions are being added to C++ 0X, and may make it in to C1X, but that's not going to be for a while. I do not know if the macros in the link I gave will increase the size of your binaries. I would suspect they would not, at least if you compile at a reasonable level of optimisation, but your mileage may vary.
If your compiler sets a preprocessor macro like DEBUG or NDEBUG you can make something like this (otherwise you could set this up in a Makefile):
#ifdef DEBUG
#define MY_COMPILER_ASSERT(EXPRESSION) switch (0) {case 0: case (EXPRESSION):;}
#else
#define MY_COMPILER_ASSERT(EXPRESSION)
#endif
Then, your compiler asserts only for debug builds.
Using '#error' is a valid preprocessor definition that causes compilation to stop on most compilers. You can just do it like this, for example, to prevent compilation in debug:
#ifdef DEBUG
#error Please don't compile now
#endif
I know you're interested in C, but take a look at boost's C++ static_assert. (Incidentally, this is likely becoming available in C++1x.)
We've done something similar, again for C++:
#define COMPILER_ASSERT(expr) enum { ARG_JOIN(CompilerAssertAtLine, __LINE__) = sizeof( char[(expr) ? +1 : -1] ) }
This works only in C++, apparently. This article discusses a way to modify it for use in C.
When you compile your final binaries, define MY_COMPILER_ASSERT to be blank, so that its output isn't included in the result. Only define it the way you have it for debugging.
But really, you aren't going to be able to catch every assertion this way. Some just don't make sense at compile time (like the assertion that a value is not null). All you can do is verify the values of other #defines. I'm not really sure why you'd want to do that.
I found this to give the least confusing error message for GCC. Everything else had some suffix about a negative size or some other confusing thing:
#define STATIC_ASSERT(expr, msg) \
typedef char ______Assertion_Failed_____##msg[1]; __unused \
typedef char ______Assertion_Failed_____##msg[(expr)?1:2] __unused
example usage:
unsigned char testvar;
STATIC_ASSERT(sizeof(testvar) >= 8, testvar_is_too_small);
And the error message in gcc (ARM/GNU C Compiler : 6.3.1):
conflicting types for '______Assertion_Failed_____testvar_is_too_small'
Well, you could use the static asserts in the boost library.
What I believe they do there, is to define an array.
#define MY_COMPILER_ASSERT(EXPRESSION) char x[(EXPRESSION)];
If EXPRESSION is true, it defines char x[1];, which is OK. If false, it defines char x[0]; which is illegal.
I was going through a header file of a micro-controller, when i found this,
#define DEFA(name, address) __no_init union \
{ \
struct \
{ \
volatile unsigned char name##_L; \
volatile unsigned char name##_H; \
}; \
struct \
{ \
volatile unsigned short name##L; \
volatile unsigned short name##H; \
}; \
__ACCESS_20BIT_REG__ name; \
} # address;
I have multiple questions here,
I didn't know that we can use union and structures within #define statements. How are they interpreted by the compiler?
What does "name##_L" and "name##L" mean.?, especially "##".
What is "__ACCESS_20BIT_REG__ name"?
What is this new "#" symbol, I googled to find out about this symbol, and i find nothing related to the # symbol anywhere, some people say that this is not C standard, is this true?, and what does it mean?
Someone, please explain me this peace of code, everything depends on this piece of the code, and everything either directly or indirectly uses this #define. :(
You can put most things inside macros, they are mostly just text replacement (though on a token by token level). Putting typedefs and variable declarations inside macros is however bad practice and should be avoided unless there's no other option.
It pastes the token past and creates a new pre-processor token. In this case it creates member variable names. If you use DEFA(foo,0) you will get members named foo_H and foo_L.
Notably, this particular macro would probably have been better if the fields were just named H and L. Why would anyone want to type reg.foo_H rather than foo.H? Using _L versus L postfix to distinguish between 8 and 16 bit access is not a very bright idea either.
Some custom type used by the same code. Why they have a union between something called "20 bit" and 32 bit structs, I have no idea.
A non-standard extension. Usually it is used for allocation of a variable at a specific address, which is the case here. Probably you have a memory-mapped hardware register and this macro is supposed to be a generic declaration for such registers.
Also notable, the union syntax isn't standard C. You need to name the union. The anonymous structs are standard C since C11, but I doubt this is from a modern compiler.
Overall, very bad code. A very typical kind of trash code you find in microcontroller register maps delivered by silicon/tool vendors. Not compliant with ISO C nor MISRA-C.
I didn't know that we can use union and structures within #define statements. How are they interpreted by the compiler?
Define statements are just macros. They are NOT interpreted by the compiler but by the preprocessor. That bit of code that is defined inside the macro is just copy-pasted everywhere, where you call/use that macro. If it contains valid C/C++ code, then it will compile in the next step also, once the preprocessor is done.
What does "name##_L" and "name##L" mean.?, especially "##".
Yes, I was surprised by this ## once upon a time also. It is token concatenation. Basically, you can generate 'programmatically' variable/function names using it. So for example, you have,
#include <stdio.h>
#define concat(a, b) a##b
int main(void)
{
int foobar = 1;
printf("%d", concat(foo, bar));
return 0;
}
would print 1, as it concatenates foo and bar together to form foobar.
What is "__ACCESS_20BIT_REG__ name"?
__ACCESS_20BIT_REG__ seems to be an implementation-defined macro defined probably somewhere else in the code. The __ double underscore followed by a capital are reserved for implementation (so that they can be used for example by your uC manufacturer).
What is this new "#" symbol, I googled to find out about this symbol, and i find nothing related to the # symbol anywhere, some people say that this is not C standard, is this true?, and what does it mean?
This one has me stumped also. I don't think this is legal C.
EDIT:
Actually, regarding your point 4 i.e. the # synmbol, I googled some more and found this stackoverflow question.
I think the best way to explain this piece of code is by trying an example:
So what results from the define DEFA(name, address)?
Using the define like e.g. DEFA(myName, myAddress) the preprocessor creates these lines of code:
__no_init union
{
struct
{
volatile unsigned char myName_L;
volatile unsigned char myName_H;
};
struct
{
volatile unsigned short myNameL;
volatile unsigned short myNameH;
};
__ACCESS_20BIT_REG__ myName;
} # myAddress;
So now to your questions:
Interpreted as shown
This is called token concatenation, is concates the given token to to an marco variableen.wikipedia.org/wiki/C_preprocessor#Token_concatenation
ACCESS_20BIT_REG is probably a 20bit long data type marcro whick is defined somewhere else
With GCC & Clang you can deprecate struct members, (as shown below).
However I didn't see a way to do this for other compilers (MSVC for example).
While this isn't apart of the C spec and most likely relies on pragma's or custom extensions for each compiler, it would be useful to be able to support this across a wider range of compilers.
/* mytest.h */
#ifdef __GNUC__
# define ATTR_DEPRECATED __attribute__((deprecated))
#else
# define ATTR_DEPRECATED /* unsupported compiler */
#endif
struct Test {
int bar;
int foo ATTR_DEPRECATED;
};
Once a member is deprecated, the compiler should warn of its use if its accessed directly, eg:
#include "mytest.h"
static func(void)
{
Test t;
t.bar = 1;
t.foo = 0; /* <-- WARN ABOUT THIS AT COMPILE TIME */
}
Besides compilers which support GCC's __attribute__((deprecated)) (Clang for example) there aren't conventions for MSVC to deprecate struct members (With MSVC you can deprecate the identifier but that applies globally, not just to that struct).
Also no other conventions for other C compilers have been posted. So it looks like this is GCC specific.
Put simply, there isn't a one-way fits all thing here. Some compilers simply don't support such ideas. I will suggest something along the lines of this however, duplicated here (with some modification):
#ifdef __GNUC__
#define ATTR_DEPRECATED __attribute__((deprecated))
#elif defined _MSC_VER
//List of deprecated values
#pragma deprecated(values)
#endif
Unfortunately, this requires a #pragma line for every deprecated member but hey.
Also, as ideasman points out in the comments, the deprecated pragma is global, so if you have an instance with the same name as your struct member anywhere, it will be marked.
Perhaps something more along the lines of this:
#ifdef __GNUC__
#define DEPRECATED(x) x __attribute__((deprecated))
#elif defined _MSC_VER
#define DEPRECATED(x) __pragma deprecated(x)
#else
#define DEPRECATED(x) x
#endif
edit: this is based on Quirliom's answer
2nd edit: fixed #pragma to be __pragma as suggested by ideasman42
If all of deprecated structure members have names which are unique to the structure, it may be possible to replace the structure with one that contains an array of a structure containing the real values but slightly different names, and then use #define to create macros that define all of the structure's elements.
For example, if the old structure was:
typedef struct {
int FOO_first;
int FOO_second;
long FOO_third;
} FOO;
one could replace it with:
#define WARNING_ZERO (2u < -1) // An expression which will yield a constant zero but print a warning
#define FOO_second (FOOO_second[WARNING_ZERO])
typedef struct {
int FOO_first;
int FOOO_second[1];
long FOO_third;
}
Unfortunately, I don't know any way to make that technique work in C if the names of any deprecated items are used as identifiers for any other purpose.
#define TYPE char *
if TYPE is char *
do A
if TYPE is int
do B
Is there an example how to do such things?
C preprocessor MACROS manipulate text, so are essentially typeless, so NO you can't do that.
You could associate another symbol with it:
#define TYPE char *
#define TYPE_IS_CHAR_STAR
#ifdef TYPE_IS_CHAR_STAR
...
#endif
You just need to keep them consistent manually.
Note that that's a dangerous macro; you should use a typedef instead. With the macro:
TYPE x, y;
x is a pointer, but y isn't.
You can get a similar effect by defining another macro along with the type, and using #ifdef etc. with that other macro. For example:
#define TYPE char *
#define TYPE_IS_PCHAR 1
...then later...
#ifdef TYPE_IS_PCHAR
do A
#endif
#ifdef TYPE_IS_INT
do B
#endif
It's not quite the same thing, but it still gets you there.
Not easily. You could do something like:
#define TYPE_IS_CHARPTR
//#define TYPE_IS_INT
#ifdef TYPE_IS_CHARPTR
do A
#endif
#ifdef TYPE_IS_INT
do B
#endif
But you really should be trying to minimise your use of the preprocessor for tricky things (anything other than simple variables).
With enumerated constants and inline functions, there's little need for such uses nowadays.
It would work if you just used basic types (since they're just strings - see Mitch's answer). But as soon as you try to use pointers, it won't work any more - the asterisk throws the preprocessor for a loop:
[holt#Michaela ~]$ gcc test.c
test.c:3:10: error: operator '*' has no right operand
But if you want do do different things based on different types, I'm going to have to recommend switching to C++ and using templates and template specialization. Reluctantly, since template syntax is incredibly ugly, but you should be able to do whatever you want.
Hope that helps!
I'd like to implement an "assert" that prevents compilation, rather than failing at runtime, in the error case.
I currently have one defined like this, which works great, but which increases the size of the binaries.
#define MY_COMPILER_ASSERT(EXPRESSION) switch (0) {case 0: case (EXPRESSION):;}
Sample code (which fails to compile).
#define DEFINE_A 1
#define DEFINE_B 1
MY_COMPILER_ASSERT(DEFINE_A == DEFINE_B);
How can I implement this so that it does not generate any code (in order to minimize the size of the binaries generated)?
A compile-time assert in pure standard C is possible, and a little bit of preprocessor trickery makes its usage look just as clean as the runtime usage of assert().
The key trick is to find a construct that can be evaluated at compile time and can cause an error for some values. One answer is the declaration of an array cannot have a negative size. Using a typedef prevents the allocation of space on success, and preserves the error on failure.
The error message itself will cryptically refer to declaration of a negative size (GCC says "size of array foo is negative"), so you should pick a name for the array type that hints that this error really is an assertion check.
A further issue to handle is that it is only possible to typedef a particular type name once in any compilation unit. So, the macro has to arrange for each usage to get a unique type name to declare.
My usual solution has been to require that the macro have two parameters. The first is the condition to assert is true, and the second is part of the type name declared behind the scenes. The answer by plinth hints at using token pasting and the __LINE__ predefined macro to form a unique name possibly without needing an extra argument.
Unfortunately, if the assertion check is in an included file, it can still collide with a check at the same line number in a second included file, or at that line number in the main source file. We could paper over that by using the macro __FILE__, but it is defined to be a string constant and there is no preprocessor trick that can turn a string constant back into part of an identifier name; not to mention that legal file names can contain characters that are not legal parts of an identifier.
So, I would propose the following code fragment:
/** A compile time assertion check.
*
* Validate at compile time that the predicate is true without
* generating code. This can be used at any point in a source file
* where typedef is legal.
*
* On success, compilation proceeds normally.
*
* On failure, attempts to typedef an array type of negative size. The
* offending line will look like
* typedef assertion_failed_file_h_42[-1]
* where file is the content of the second parameter which should
* typically be related in some obvious way to the containing file
* name, 42 is the line number in the file on which the assertion
* appears, and -1 is the result of a calculation based on the
* predicate failing.
*
* \param predicate The predicate to test. It must evaluate to
* something that can be coerced to a normal C boolean.
*
* \param file A sequence of legal identifier characters that should
* uniquely identify the source file in which this condition appears.
*/
#define CASSERT(predicate, file) _impl_CASSERT_LINE(predicate,__LINE__,file)
#define _impl_PASTE(a,b) a##b
#define _impl_CASSERT_LINE(predicate, line, file) \
typedef char _impl_PASTE(assertion_failed_##file##_,line)[2*!!(predicate)-1];
A typical usage might be something like:
#include "CAssert.h"
...
struct foo {
... /* 76 bytes of members */
};
CASSERT(sizeof(struct foo) == 76, demo_c);
In GCC, an assertion failure would look like:
$ gcc -c demo.c
demo.c:32: error: size of array `assertion_failed_demo_c_32' is negative
$
The following COMPILER_VERIFY(exp) macro works fairly well.
// combine arguments (after expanding arguments)
#define GLUE(a,b) __GLUE(a,b)
#define __GLUE(a,b) a ## b
#define CVERIFY(expr, msg) typedef char GLUE (compiler_verify_, msg) [(expr) ? (+1) : (-1)]
#define COMPILER_VERIFY(exp) CVERIFY (exp, __LINE__)
It works for both C and C++ and can be used anywhere a typedef would be allowed. If the expression is true, it generates a typedef for an array of 1 char (which is harmless). If the expression is false, it generates a typedef for an array of -1 chars, which will generally result in an error message. The expression given as an arugment can be anything that evaluates to a compile-time constant (so expressions involving sizeof() work fine). This makes it much more flexible than
#if (expr)
#error
#endif
where you are restricted to expressions that can be evaluated by the preprocessor.
As Leander said, static assertions are being added to C++11, and now they have.
static_assert(exp, message)
For example
#include "myfile.hpp"
static_assert(sizeof(MyClass) == 16, "MyClass is not 16 bytes!")
void doStuff(MyClass object) { }
See the cppreference page on it.
The best writeup that I could find on static assertions in C is at pixelbeat. Note that static assertions are being added to C++ 0X, and may make it in to C1X, but that's not going to be for a while. I do not know if the macros in the link I gave will increase the size of your binaries. I would suspect they would not, at least if you compile at a reasonable level of optimisation, but your mileage may vary.
If your compiler sets a preprocessor macro like DEBUG or NDEBUG you can make something like this (otherwise you could set this up in a Makefile):
#ifdef DEBUG
#define MY_COMPILER_ASSERT(EXPRESSION) switch (0) {case 0: case (EXPRESSION):;}
#else
#define MY_COMPILER_ASSERT(EXPRESSION)
#endif
Then, your compiler asserts only for debug builds.
Using '#error' is a valid preprocessor definition that causes compilation to stop on most compilers. You can just do it like this, for example, to prevent compilation in debug:
#ifdef DEBUG
#error Please don't compile now
#endif
I know you're interested in C, but take a look at boost's C++ static_assert. (Incidentally, this is likely becoming available in C++1x.)
We've done something similar, again for C++:
#define COMPILER_ASSERT(expr) enum { ARG_JOIN(CompilerAssertAtLine, __LINE__) = sizeof( char[(expr) ? +1 : -1] ) }
This works only in C++, apparently. This article discusses a way to modify it for use in C.
When you compile your final binaries, define MY_COMPILER_ASSERT to be blank, so that its output isn't included in the result. Only define it the way you have it for debugging.
But really, you aren't going to be able to catch every assertion this way. Some just don't make sense at compile time (like the assertion that a value is not null). All you can do is verify the values of other #defines. I'm not really sure why you'd want to do that.
I found this to give the least confusing error message for GCC. Everything else had some suffix about a negative size or some other confusing thing:
#define STATIC_ASSERT(expr, msg) \
typedef char ______Assertion_Failed_____##msg[1]; __unused \
typedef char ______Assertion_Failed_____##msg[(expr)?1:2] __unused
example usage:
unsigned char testvar;
STATIC_ASSERT(sizeof(testvar) >= 8, testvar_is_too_small);
And the error message in gcc (ARM/GNU C Compiler : 6.3.1):
conflicting types for '______Assertion_Failed_____testvar_is_too_small'
Well, you could use the static asserts in the boost library.
What I believe they do there, is to define an array.
#define MY_COMPILER_ASSERT(EXPRESSION) char x[(EXPRESSION)];
If EXPRESSION is true, it defines char x[1];, which is OK. If false, it defines char x[0]; which is illegal.