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.
Related
Reading a chapter on the preprocessor, it stated that redefinition of macros is allowed only if the redefinition matches the previous definition, i.e:
#define FOO 0
#define BAR 1+1
#define FOO 0 /* ok. */
#define BAR 1 + 1 /* not ok */
I'm baffled by this.
Granted that this behavior is actually correct (the book might be wrong, of course), my question is: Why allow this? I can't think of any legitimate use-cases where this might be used (granted I don't have the experience), is there a rational behind it?
The idea is to make preprocessor to actively watch repetitive definitions and ensure that they remain identical.
The rationale behind this rule is actually mentioned in the Rationale to C99 standard
The Committee desired to disallow “pernicious redefinitions” such as
(in header1.h)
#define NBUFS 10
(in header2.h)
#define NBUFS 12
which are clearly invitations to serious bugs in a program. There remained, however, the question of “benign redefinitions,” such as
(in header1.h)
#define NULL_DEV /* the first time */ 0
(in header2.h)
#define NULL_DEV /* the second time */ 0
The C89 Committee concluded that safe programming practice is better served by allowing benign redefinition where the definitions are the same. This allows independent headers to specify their understanding of the proper value for a symbol of interest to each, with diagnostics generated only if the definitions differ.
Basically, the idea is to deliberately catch and expose situations when two definitions exist and they are different. If users were always forced to anticipate and #undef the previous definition before defining their own, they would quietly override what was not intended to be overridden, without a way to ensure consistency.
By deliberately supplying an extra identical definition you effectively introduce an extra level of protection: if someone modifies the previous definition, the preprocessor will immediately catch and report the resulting mismatch.
In other words by defining
#define A 42
in your code you are not only defining A as 42, you are also telling the preprocessor that you want to ensure that everyone else (in this translation unit) shares the same idea of what A should be.
Your book is strictly correct but perhaps fails to point out - or you might overlooked it -
that you may redefine a previously defined preprocessor with no diagnostic provided
that you undefine it before you redefine it. E.g:
#define FOO 0
#define BAR 1+1
#define FOO 0 /* ok. */
#undef BAR
#define BAR 1 + 1 /* ok */
If you attempt to redefine a macro while it is defined there's a high probability
you're committing a blunder and would be grateful for the preprocessor to
draw that to your attention.
When you define a macro in a file that inhabits a large, complex
product codebase - which perhaps has multiple, intertwined build-configurations
controlled by macros that are ultimately defined outside the codebase,
in the build system - then it may be beyond your unaided wits to know that
your definition will never, disastrously, contradict a prior definition in building any
configuration. You'd want to know that, and the preprocessor will tell you.
On the other hand, there are circumstances where you want say: FOO may or
may not have got a prior definition from somewhere at the point where my
file is compiled. Regardless, I want it to have my definition now.
I know what I'm doing and on my head be it. The preprocessor lets you assume that
responsibility as in:
foo.c
#include <bar.h>
...
#undef FOO // I don't care what it previously might have been.
#define FOO what I want here
and keeps quiet.
In that light, the question of why the preprocessor does not complain of
a macro redefinition that doesn't differ from the last one is probably
dispelled. Identical redefinitions are harmless. Useless, yes, but not
necessarily implying that you, or anyone, has repeated themselves. Library
header files libfoo.h and libbar.h might both be included in baz.c and
each of them might contain.
#define MAX_HANDLES 255
which the preprocessor will see twice. But it's harmless, so why complain?
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.
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.
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.