The documentation for GCC's __attribute__((...)) syntax indicates that attributes must be surrounded by double parentheses, but does not give a rationale for this design decision.
What practical reason would have caused GCC's designers to require this? Does it have anything to do with the preprocessor's handling of double parentheses?
To make it easier to eliminate it for different compiler. If you have portable code, you have to remove them for other compilers, so you do
#ifndef __GNUC__
#define __attribute__(x)
#endif
The problem is that attributes have various number of arguments and you can combine multiple attributes in one __attribute__ declaration, but C only introduced variadic macros in C99. With double parenthesis the above definition does not need variadic macros.
probably the idea is that you can declare a simple macro that helps to ignore all this in any other C and C++ compiler. If you wouldn't have the second pair of parenthesis that macro would be necessarily one with .... So for compilers that don't support that you would be screwed.
Edit: With this syntax it can simply look like
#ifdef __GNUC__
# define attribute(X) __attribute__(X)
#else
# define attribute(X)
#endif
and then you would use attribute for your function declarations, e.g.
Related
In a codebase that can be built as either C or C++, I thought I'd make a macro to take advantage of static_assert in the case it's built as C++11 or higher.
(Note: I know there are ways to do this in pre-C11 C, at least if you're willing to take a message parameter--though it won't work quite everywhere. But for the sake of argument let's say I have some legitimate need to make it take no message, and be a no-op in at least some C builds.)
So here was the simple definition I tried:
#if defined(__cplusplus) && __cplusplus >= 201103L
#define STATIC_ASSERT(cond) \
static_assert((cond), #cond)
#else
#define STATIC_ASSERT(cond)
#endif
There's no semicolon in the macro, with the intent that you would add it at the callsite. But under pedantic C warning settings, this macro appearing in global scope causes:
error: ISO C does not allow extra ‘;’ outside of a function [-Werror=pedantic]
The easy solution seems to be to take the semicolon off the callsites, and put it in the C++11 side of the macro. But I wonder: how do you make a no-op macro in global scope which allows a semicolon at the callsite (without running afoul of some other warning)?
Since forward declarations of structures may be repeated as much as we want, you can use a dummy declaration:
#define STATIC_ASSERT(cond) struct GlobalScopeNoopTrick
#JonathanLeffler says this should work in older compilers, even pre-C11...but:
"If you have a C90 compiler, it would object if you had a static assert after a statement in a compound statement. This is not your primary concern (it’ll always be OK at file scope if the static assert is OK too), but it isn’t limited to being used at file scope. The risk is low, though"
For related situations that might not be entirely no-ops at compile-time, C11 introduced the ability to repeat typedefs. And as in the post linked about static asserts in C prior to _Static_assert() shows, there are ways to get around typedef duplication for older C using the line number or another disambiguator:
/* Standard indirection to allow concatenation after expansion */
#define CONCAT(a,b) CONCAT_(a,b)
#define CONCAT_(a,b) a##b
#if defined(__cplusplus) && __cplusplus >= 201103L
#define STATIC_ASSERT(cond) \
static_assert((cond), #cond)
#else
#define STATIC_ASSERT(cond) typedef void CONCAT(dummy_unused_,__LINE__)
#endif
So long as static assertions appear one per line the identifiers won't conflict with each other.
How do I keep __builtin_prefetch() in my code, but make compilers that do not have it compile successfully? (Just doing nothing where it is found).
__builtin_prefetch() is recognised by the compiler (gcc) not the preprocessor, so you won't be able to detect it using the C preprocessor.
Since an identifier with two leading underscores is reserved for use by the implementation (so any code you use which defines such an identifier has undefined behaviour) I'd do it the other way around.
#ifdef __GNUC__
#define do_prefetch(x) __builtin_prefetch(x)
#else
#define do_prefetch(x)
#endif
and then use
do_prefetch(whatever);
where needed.
That way there is no code emitted unless it is actually needed.
Since __builtin_prefetch() accepts a variable number of arguments, you might want to adapt the above to use variadic macros (C99 and later) - if you use it with different numbers of arguments in different places in your code.
It is not exactly the best solution, but it will disable __builtin_prefetch() on all other compilers other than GCC.
#ifndef __GNUC__
# define __builtin_prefetch(x)
#endif
While looking at the sqrt function for tgmath.h,
I see that there is a type-generic macro for C99.
I know how I would implement it with Generic selection,
but _Generic did not exist until C11.
We have legacy projects in C89, and C99.
I would like to implement type generic functionality in a similar fashion if possible.
How does one write type generic macros in C without Generic selection?
How did C99 do type generic macros without _Generic (C11)?
Non-portably.
There is no general way to write a type-generic macro in pre-C11 C.
If you look at the tgmath.h header provided as part of glibc, for example, it doesn't use _Generic (since it needs to work with compilers that don't support _Generic). Instead, it uses a number of gcc-specific features such as __builtin_classify_type wrapped in some remarkable macros. A comment near the top of the file says:
/* This is ugly but unless gcc gets appropriate builtins we have to do
something like this. Don't ask how it works. */
Some of the macro definitions compare sizeof (Val) (where Val is the macro argument) vs. sizeof (double). This could fail if float, double, and long double do not all have distinct sizes.
And the whole thing is wrapped in:
#if __GNUC_PREREQ (2, 7)
/* a lot of ugly macro definitions */
#else
# error "Unsupported compiler; you cannot use <tgmath.h>"
#endif
You could probably throw something together using sizeof, but it would be ugly.
Is there any chance you could compile your legacy code with a compiler that supports C11, or at least the _Generic feature?
In many places I see the usage of undefine macro before defining the same macro. For example:
#undef FORMULA
#ifdef SOMETHING
#define FORMULA 1
#else
#define FORMULA 2
#endif
What for the #undefine FORMULA used?
I may guess that it deals with the case when the macro was already defined before. But isn't the new definition overrides the old one? Thanks!
A macro name currently defined cannot be redefined with a different definition (see below), so #undef allows that macro name to be redefined with a different definition.
Here's the relevant legalese:
Both C and C++ Standards (same wording):
A macro definition lasts (independent of block structure) until a corresponding #undef directive is encountered or (if none is encountered) until the end of the preprocessing translation unit.
Slight differences in wording, same meaning:
C Standard (N1256), §6.10.3/2:
An identifier currently defined as an object-like macro shall not be redefined by another #define preprocessing directive unless the second definition is an object-like macro definition and the two replacement lists are identical. Likewise, an identifier currently defined as a function-like macro shall not be redefined by another #define preprocessing directive unless the second definition is a function-like macro definition that has the same number and spelling of parameters, and the two replacement lists are identical.
C++ Standard (N3337) §16.3/2
An identifier currently defined as an object-like macro may be redefined by another #define preprocessing directive provided that the second definition is an object-like macro definition and the two replacement lists are identical, otherwise the program is ill-formed. Likewise, an identifier currently defined as a function-like macro may be redefined by another #define preprocessing directive provided that the second definition is a function-like macro definition that has the same number and spelling of parameters, and the two replacement lists are identical, otherwise the program is ill-formed.
Same wording in both Standards:
Two replacement lists are identical if and only if the preprocessing tokens in both have the same number, ordering, spelling, and white-space separation, where all white-space separations are considered identical.
So:
#define X(y) (y+1)
#define X(z) (z+1) // ill-formed, not identical
IMHO, using #undef is generally dangerous due to the scoping rules for preprocessor macros. I'd prefer to get a warning or error from the preprocessor and come up with a different preprocessor macro rather than have some translation unit silently accept a wrong macro definition that introduces a bug into the program. Consider:
// header1.h
#undef PORT_TO_WRITE_TO
#define PORT_TO_WRITE_TO 0x400
// header2.h
#undef PORT_TO_WRITE_TO
#define PORT_TO_WRITE_TO 0x410
and have a translation unit #include both headers. No warning, probably not the intended result.
Yes, the new definition overrides all previous. But there is corresponding warning message. With #undef you have no warnings.
But isn't the new definition overrides the old one?
Yes, it does (when your compiler allows it). However, redefining a macro results in a compiler warning, which using #undefine lets you avoid.
This may be important in programming shops with strict rules on compiler warnings - for example, by requiring all production code to be compiled with -Werror flag, which treats all warnings as errors.
#undef removes the macro, so the name is free to be defined again.
If the macro was never defined in the first place, #undef has no effect, so there's no downside. #undef … #define should be read as replacing any potential previous definition, but not to imply that it must already be defined.
Popular compilers do allow you to skip the #undef, but this is not allowed by the official standard ISO C and C++ language specifications. It is not portable to do so.
What is the replacement of __attribute__ in ISO C standard?
I want to port my software which is compiler independent.
There isn't one.
One solution is to abstract the attributes behind macros. e.g.:
#ifdef __GNUC__
#define UNUSED __attribute((unused))__
#else
#define UNUSED
#endif
...
void function(void) UNUSED;
There is no general replacement for the wide range of facilities that this gcc extension offers. Most other compilers that are not gcc compatible use #pragma to achieve similar goals. Since C99, C has the _Pragma operator that allows you to spew pragmas in the middle of your code (not only on proper lines) and to compose the contents of a pragma with macros. But then you still have to do specific "translations" of individual features to the corresponding pragma syntax of your target compiler.