Is there any way to prevent gcc from expanding a macro in this:
#define putc(a) fputc(a)
...
void _putc(char ch) {}
struct foo { void *(putc)(char ch); }
struct foo f = {_putc;}
(&f)->putc('X'); // this is an error because it gets expanded into fputc, which is very inappropriate.
I don't want to use #undef putc because it messes up other things.
Including <stdio.h> may or may not define macro functions. In either case, a real function is provided.
It's probably not the best idea to name a function pointer like a standard library function, but you can do it. To prevent macro expansion, you have basically three options:
#undef it. You said this would mess up other things, though this shouldn't be a problem -- a real function with that name still exists. For some functions, you may miss optimizations or warnings (for functions like printf, for example), however (depending on your compiler).
Don't include the header file and declare the function yourself. I mention this for sake of completeness rather than as a real suggestion. This doesn't work if you need a type definition provided only in the header you don't want to include.
Don't put an opening parenthesis after the macro name, as in
((&f)->putc)('X'); // or (f.putc)('X'); -- looking less confusing.
Related
To avoid impossible situation one could reduce the problem to two cases.
Case 1
The first (simplest) case is situation where the preprocessor has a chance to detect it, that is there's a preprocessor directive that depends on a macro being predefined (that is defined before the first line of input) or not. For example:
#ifdef FOO
#define BAR 42
#else
#define BAR 43
#endif
depends on FOO being predefined or not. However the file
#undef FOO
#ifdef FOO
#define BAR 42
#endif
does not. A harder case would be to detect if the dependency actually does matter, which it doesn't in the above cases (as neither FOO or BAR affects the output).
Case 2
The second (harder) case is where successful compilation depends on predefined macros:
INLINE int fubar(void) {
return 42;
}
which is perfectly fine as far as the preprocessor is concerned whether or not ENTRY_POINT is predefined, but unless INLINE is carefully defined that code won't compile. Similarily we could in this case it might be possible to exclude cases where the output isn't affected, but I can't find an example of that. The complication here is that in the example:
int fubar(void) {
return 42;
}
the fubar being predefined can alter the successful compilation of this, so one would probably need to restrict it to cases where a symbol need to be predefined in order to compile successfully.
I guess such a tool would be something similar to a preprocessor (and C parser in the second case). The question is if there is such a tool? Or is there a tool that only handles the first case? Or none at all?
In C everything can be (re)defined, so there is no way to know in advance what is intended to be (re)defined. Usually some naming conventions helps us to figure out what is meant to be a macro (like upper-case). Therefore it is not possible to have such tool. Of course if you assume that the compilation errors are caused by missing macro definitions then you can use them to analyze what is missing.
I found some legacy code with something similar to the following. Say I have the following definition:
#define FOO(x) bar
x is never referenced in the definition. So, does that mean that whatever text is placed within FOO() is irrelevant?
The code I'm looking at is scattered with calls such as FOO(someValue); I'm assuming the preprocessor is replacing the entire statement with simply bar, no matter what someValue is? A little thrown off by why x is present at all.
Yes, FOO(whatever) is completely replaced with bar in your example.
Macros like this are often seen in "configure-able" code, like:
#if defined(ENABLE_DEBUG_PRINT)
#define DEBUG_PRINT(msg) printf("Here's a message: %s\n", msg)
#else
#define DEBUG_PRINT(msg) /* empty */
#endif
Nothing special happens. Any occurrence of x in the macro definition is expanded to the value of the corresponding argument when the macro is expanded. If there is no such occurrence, it's not expanded (and the actual value of the argument is irrelevant).
As for why it's there, it may be that some past or potential future version of the macro might make some use of the argument. Perhaps it's one of several macros that take a single argument, and it's defined that way for consistency. It's impossible to tell without more context. But the macro definition is perfectly valid.
What happens is exactly what you thought would happen—the value is ignored.
I recommend running the preprocessor (gcc -E or cpp (possibly add -x c++ for c++)) to actually see what actually happens on your implementation instead of just guessing.
Yes, macro FOO() expands to bar regardless of its argument. This is not different in nature from how a function can ignore some or all of its parameters.
The macro may be a place holder for a possible future implementation that does use its argument, or a replacement for an older implementation that did. It may also be that the definition of macro FOO() is different in different places, and that some of the definitions use their argument. If it isn't any of those, nor similar, then it's just obfuscatory.
So, does that mean that whatever text is placed within FOO() is irrelevant?
Unless there's a conditionally-compiled alternative version of FOO() where x is actually used. You might that to only evaluate the expression x in the debug build, for instance.
This statement just consumes the x expression without using it.
For instance, if you want to stub some methods you can use that.
I am trying to use a function-like macro to generate an object-like macro name (generically, a symbol). The following will not work because __func__ (C99 6.4.2.2-1) puts quotes around the function name.
#define MAKE_AN_IDENTIFIER(x) __func__##__##x
The desired result of calling MAKE_AN_IDENTIFIER(NULL_POINTER_PASSED) would be MyFunctionName__NULL_POINTER_PASSED. There may be other reasons this would not work (such as __func__ being taken literally and not interpreted, but I could fix that) but my question is what will provide a predefined macro like __func__ except without the quotes? I believe this is not possible within the C99 standard so valid answers could be references to other preprocessors.
Presently I have simply created my own object-like macro and redefined it manually before each function to be the function name. Obviously this is a poor and probably unacceptable practice. I am aware that I could take an existing cpp program or library and modify it to provide this functionality. I am hoping there is either a commonly used cpp replacement which provides this or a preprocessor library (prefer Python) which is designed for extensibility so as to allow me to 'configure' it to create the macro I need.
I wrote the above to try to provide a concise and well defined question but it is certainly the Y referred to by #Ruud. The X is...
I am trying to manage unique values for reporting errors in an embedded system. The values will be passed as a parameter to a(some) particular function(s). I have already written a Python program using pycparser to parse my code and identify all symbols being passed to the function(s) of interest. It generates a .h file of #defines maintaining the values of previously existing entries, commenting out removed entries (to avoid reusing the value and also allow for reintroduction with the same value), assigning new unique numbers for new identifiers, reporting malformed identifiers, and also reporting multiple use of any given identifier. This means that I can simply write:
void MyFunc(int * p)
{
if (p == NULL)
{
myErrorFunc(MYFUNC_NULL_POINTER_PASSED);
return;
}
// do something actually interesting here
}
and the Python program will create the #define MYFUNC_NULL_POINTER_PASSED 7 (or whatever next available number) for me with all the listed considerations. I have also written a set of macros that further simplify the above to:
#define FUNC MYFUNC
void MyFunc(int * p)
{
RETURN_ASSERT_NOT_NULL(p);
// do something actually interesting here
}
assuming I provide the #define FUNC. I want to use the function name since that will be constant throughout many changes (as opposed to LINE) and will be much easier for someone to transfer the value from the old generated #define to the new generated #define when the function itself is renamed. Honestly, I think the only reason I am trying to 'solve' this 'issue' is because I have to work in C rather than C++. At work we are writing fairly object oriented C and so there is a lot of NULL pointer checking and IsInitialized checking. I have two line functions that turn into 30 because of all these basic checks (these macros reduce those lines by a factor of five). While I do enjoy the challenge of crazy macro development, I much prefer to avoid them. That said, I dislike repeating myself and hiding the functional code in a pile of error checking even more than I dislike crazy macros.
If you prefer to take a stab at this issue, have at.
__FUNCTION__ used to compile to a string literal (I think in gcc 2.96), but it hasn't for many years. Now instead we have __func__, which compiles to a string array, and __FUNCTION__ is a deprecated alias for it. (The change was a bit painful.)
But in neither case was it possible to use this predefined macro to generate a valid C identifier (i.e. "remove the quotes").
But could you instead use the line number rather than function name as part of your identifier?
If so, the following would work. As an example, compiling the following 5-line source file:
#define CONCAT_TOKENS4(a,b,c,d) a##b##c##d
#define EXPAND_THEN_CONCAT4(a,b,c,d) CONCAT_TOKENS4(a,b,c,d)
#define MAKE_AN_IDENTIFIER(x) EXPAND_THEN_CONCAT4(line_,__LINE__,__,x)
static int MAKE_AN_IDENTIFIER(NULL_POINTER_PASSED);
will generate the warning:
foo.c:5: warning: 'line_5__NULL_POINTER_PASSED' defined but not used
As pointed out by others, there is no macro that returns the (unquoted) function name (mainly because the C preprocessor has insufficient syntactic knowledge to recognize functions). You would have to explicitly define such a macro yourself, as you already did yourself:
#define FUNC MYFUNC
To avoid having to do this manually, you could write your own preprocessor to add the macro definition automatically. A similar question is this: How to automatically insert pragmas in your program
If your source code has a consistent coding style (particularly indentation), then a simple line-based filter (sed, awk, perl) might do. In its most naive form: every function starts with a line that does not start with a hash or whitespace, and ends with a closing parenthesis or a comma. With awk:
{
print $0;
}
/^[^# \t].*[,\)][ \t]*$/ {
sub(/\(.*$/, "");
sub(/^.*[ \t]/, "");
print "#define FUNC " toupper($0);
}
For a more robust solution, you need a compiler framework like ROSE.
Gnu-C has a __FUNCTION__ macro, but sadly even that cannot be used in the way you are asking.
Notice the space in between some_name and some_function. I have seen this in a .c file and was wondering what is going on here.
int some_name some_function{
}
Thanks
EDIT:
The code in question is:
int attribute_align_arg avcodec_open(AVCodecContext *avctx, AVCodec *codec)
{
return avcodec_open2(avctx, codec, NULL);
}
It's from utils.c
One part is most likely a macro that expands to nothing (but serves documentaton) or some special attribute, like __stdcall, __declspec(noreturn), __declspec(dllexport)...
EDIT to reflect new info:
definition of yours looks like this:
51 #ifndef attribute_align_arg
52 #if ARCH_X86_32 && AV_GCC_VERSION_AT_LEAST(4,2)
53 # define attribute_align_arg __attribute__((force_align_arg_pointer))
54 #else
55 # define attribute_align_arg
56 #endif
57 #endif
That looks like either really ugly macros, or very old C. Once upon a time, C functions defaulted to returning int, and always either (depending on implementation), assumed an integer argument or allowed a variable number of arguments.
Some calling conventions require that the caller provide the arguments and then clean them up, so that would work. (If, however, the callee, that is, 'some_function', had to clean up the memory for the arguments itself, then the number of arguments is fixed).
That said, I would still strongly suspect some macro usage, possibly in addition to implied variable argumetns, despite the incredibly bad naming in the example. Does the original code contain any keywords in upper-case, or other conventions that indicate macro use? Even without those conventions, I would still suspect macros.
EDIT: The code provided in the question was completely changed. "attribute_align_arg" is likely either a macro or a compiler-specific attribute. What remains is a completely bog-standard C function, with specified arguments. As a result, Balog's answer above is the one to accept here.
I've seen many times code like this:
void func(){
#define a ...
...
#undef a
}
Is the #undef necessary at all?
It is not necessary, but the scope of a #define is global after the line it was defined. It will not obey the function scope, if you are thinking it will.
It's not necessary. If the macro is meant to be used only inside the function, it's probably a good idea to #undef it. If you don't, that just means that the macro remains visible through the rest of the translation unit (source file).
Most macros are probably intended to be visible throughout a source file anyway, so usually the question doesn't arise.
When i declare a macro like you did inside the body of a function then i would #undef it at the end. Because most probably it is meant for that function body only.
In general it is always a good idea to #undef a macro when you know that the macro definition is not going to be used anytime later because the macro definition propagate to all other files which include the file having a macro.
That depends. It is only necessary if you want to ensure that a will not be potentially available at later points in your program depending on your logic. The define is now global (in the current translation unit)!
From gnu.org:
If a macro ceases to be useful, it may be undefined with the `#undef'
directive.
Additionally,
Once a macro has been undefined, that identifier may be redefined as a
macro by a subsequent `#define' directive. The new definition need not
have any resemblance to the old definition.
and
However, if an identifier which is currently a macro is redefined,
then the new definition must be effectively the same as the old one.
Two macro definitions are effectively the same if:
Both are the same type of macro (object- or function-like).
All the tokens of the replacement list are the same.
If there are any parameters, they are the same.
Whitespace appears in the same places in both. It need not be
exactly the same amount
of whitespace, though. Remember that comments count as
whitespace.