I can do the following in GCC:
#define INIT_MODULE(name) \
({ extern int name(void); name(); })
int main(void) {
return INIT_MODULE(x);
}
Here, the function (expanded from name) is created, executed, and returned via a statement expression (GCC extension). This is a minimal repo: I am actually doing some __asm__ magic to make the name function, hence the macro.
I would like to have this be a one-liner, and not call another macro to create the name function. In my use case, the caller will only call INIT_MODULE once, and does not/should not know the name of the underlying function it is calling.
Basically, I need a way to declare, run, and return the value of a function, all in one line (without using GCC extensions!).
What I DONT want:
// ...
DECL_MODULE(x);
int main(void) {
return INIT_MODULE(x);
}
Any thoughts?
I think there's more to what you want than to simply declare, run and return the function - otherwise you could do it right away in the same manner you already achieved.
The problem that I see is that you want the function to be visible externally, as if it was declared outside of the scope of the caller. And that's clearly not possible, since #define just replaces the content of the macro (it can't move it in another point of the code).
Actually, you could use low-level goto and some arithmetics, but I'd rather not recommend you that path.
Related
Why do we need to declare global variables before function defining and declaring since we call this function after this variable declaration? Isn't it that compiler read line by line? I mean while calling the function compiler should know what's x.
void function()
{
x += 3
}
int x = 3;
int main(void)
{
function();
return 0;
}
And one more question. I know that we can define function after main function provided we declared this function before main. Then how does main function see these functions after main function? Does the compiler first read the whole file and then run main() or sth?
You can think at the job of the compiler like this; it reads the source file token by token (not exactly line by line) and when sufficient tokens are read, it outputs the translation. It repeats that, until the source file is (correctly) finished: the job of the compiler is done.
For every token the compiler reads, it needs to know what the token represents. If it doesn't know, an error is generated.
So, while compiling your function
void function()
{
x += 3
}
it encounters an "x" but does not know what it represents (an integer? A float? Something else?). -error-.
Why do we need to declare global variables before function defining and declaring
Declaration and Definition are two different things. The compiler needs a declaration in order to know how to manage an identifier; the real definition can be somewhere else, even in another source (or already compiled) file.
And one more question. I know that we can define function after main function provided we declared this function before main. Then how does main function see these functions after main function? Does the compiler first read the whole file and then run main() or sth?
As explained before, all the compiler needs is a declaration, so it can output correct (object) code. If you declare function(), then define main(), then define function(), the compiler has enough to generate correct output, which will consist of code for main() and code for function() (we can say "in this order"). The next step, the linker, will take care to connect these two functions.
The definition of function() could also be absent: the compiler still would generate correct code for main(); the linker would instead complain, unless you tell it where to find the definition/implementation of function().
Also note that a definition is also a declaration. So if in your source you declare function() and then main(), you don't need forward declaration.
In the comments I've read that perhaps you are confusing interpreters with compilers - this is true, if you try to compare Python with C: very different beasts. A big difference is compiler vs interpreter, the compiler generates data (object code) but does not link it (and neither runs it). An interpreter instead is a compiler+linker+runtime, all packed together. Normally a compiler generates code that is much faster than the equivalent interpreted program, but to do this it needs accurate informations (precise types and declarations) and often (always?) is less versatile. The interpreter is often more versatile but it can not exploit all the optimizazions a good compiler can do.
Why do we need to declare global variables before function defining
and declaring since we call this variablefunction after this
declaration?
The c language is a strictly typed language. When the compiler processes an identifier it needs to determine its type to generate correct object code.
It is not necessary that a global variable used in a function shall be declared exactly before the function definition. But in any case it shall be declared before its usage in a function.
Here is a demonstrative program.
#include <stdio.h>
void function( void )
{
extern int x;
x += 3;
}
int x = 3;
int main( void )
{
function();
printf( "x = %d\n", x );
}
The program output is
x = 6
Here the variable x declared within the function refers to the global variable x defined after the function.
Then how does main function see these functions after main function?
Does the compiler first read the whole file and then run main() or
sth?
C is a compilation language. It does not run programs. It generates object code that then after some processing by the linker can be run.
In the point where a function is used what the compiler is need is the type of the function that to check whether the function is used correctly. If the function is an inline function then it can substitute its call for the function body It can rebuild the object code when the inline definition in the translation unit will be known.
I have a function
void *custom_get_value(ObjectPtr)
This function traditionally never used to return NULL.It can return any of the following values
uint32_t
int32_t
uint64_t
int64_t
uint8_t
Since the function never used to return NULL I have a lot of code that does
*(uint32_t*)custom_get_value(ObjectPtr)
OR
*(uint64_t*)custom_get_value(ObjectPtr)
Recently we have decided to modify the behaviour of
void *custom_get_value(ObjectPtr) in such a way that it can return NULL.So all occourances of the above scenario (de-referencing to specific types without checking the return value) can result in segmentation fault.
Can I use some macro to idendify all the places in the code where the return value of
void *custom_get_value(ObjectPtr)
is not being checked.If yes how do I do that?
You can't easily write a macro that can track what happens to a value after it's been returned, because data flow analysis is somewhat beyond the preprocessor's abilities. However, there is a useful technique designed to help with situations such as this, which is to define the function you want to check as a self-referential macro:
#define custom_get_value(...) (0, custom_get_value(__VA_ARGS__))
This example doesn't do anything by itself, but it showcases something useful: when a macro name appears as part of its own replacement list, the nested occurrence of the name is "painted blue" and will not expand a second time. So by defining an existing function name as a macro, you can "wrap" (or "advise") all existing invocations of the function - presumably scattered across your code in an unknown number of places - with extra actions, in addition to retaining the original invocation.
Then you have several options, e.g.:
#define custom_get_value(...) ({ \
_Pragma("message \"custom_get_value called\""); \
custom_get_value(__VA_ARGS__); \
})
...if you're on GCC or Clang, should list the file and line number of every point where custom_get_value is called, at compile-time. (Both #pragma message and the statement expression form are nonstandard GCC extensions - but if you're only going to use this while cleaning up old calls, perhaps that doesn't matter? Once all the calls are checked you can remove the nonstandard code.)
Or apply a runtime message instead:
#define custom_get_value(...) \
custom_wrap(custom_get_value(__VA_ARGS__), __FILE__, __LINE__)
void * custom_wrap(void * val, char * f, int l) {
printf("custom_get_value called in %s on line %d\n", f, l); return val;
}
...which will drive you nuts printing a message every time the function gets called, but is at least standard.
You could even wrap all the calls with a function that renders the resulting pointer guaranteed to be non-null once again, although that's probably not the best way to deal with this situation.
Name the new function to custom_get_value_ex and delete the old one. Then your compiler will very kindly indicate all uses of the old function, so you can review them.
Generally it is a good idea to review all calls to a function anyway, when you change the semantics of a function that is already in use.
Perhaps you could wrap some of these calls in a more maintainable wrapper, e.g.
inline uint32_t custom_get_uint32(.....)
{
void *value = custom_get_value(.....);
if ( !value )
return 0; // or some other error handling
return *(uint32_t *)value;
}
Then if you change custom_get_value again , you would only have to fox this wrapper.
Even tidier would be to have a function for getting the item you are interested in:
inline uint32_t get_propeller_setting(.....)
{
void *value = custom_get_value(PROPELLER_SETTING,........)
// ....
}
Then you can have specific handling for when each value gets a null pointer returned.
Is it possible to put the variable declarations in an external function? After reading from Wikipedia that:
an inline function is a function upon which the compiler has been requested to perform inline expansion. In other words, the programmer has requested that the compiler insert the complete body of the function in every place that the function is called, rather than generating code to call the function in the one place it is defined.
I hypothesized that the following might work. It did not take long for the compiler to slap my fingers :(
inline void declaration(){
int a;
}
int main(){
declaration();
a=2;
return 0;
}
This may not be how it is done but if you want a basic idea of how you can think about what happens when you inline a function.
Imagine the compiler turning your code into something like this, then you see why it will not work.
int main(){
{
int a;
}
a=2;
return 0;
}
The call to declaration() is replaced by the contents of the function including brackets, thus int a; is declared in an inner scope and is not visible in the main function.
No, this is not possible.
What is possible, is to use a preprocessor directive #define:
#define VARBLOCK int a, b, c; char ca, cb, cc;
int main()
{
VARBLOCK;
a = 2;
}
This would be a bad practice. Also these would still be variables only available in the scope of function where it were placed, without values being shared.
No - as far as I'm aware an inline function must behave semantically equivalent to a non-inline function; it doesn't affect what counts as legal code. It's just an optimization.
In particular, you could have a variable called a in both functions, but they'd be separate variables on the stack.
(Even if you could do this, I'd suggest it would be a very bad idea in terms of readability.)
inline functions are usually just a function containing no more than about 4 lines and you would want the compiler to do the optimization you where talking about since it would be faster to do what the function does, rather than adding extra code.
Inline expansion is used to eliminate the time overhead when a function is called. It is typically used for functions that execute frequently.
So there's nothing special with the inline function, rather than it might be handled differently by the compiler. They don't share their stack with any other function, which would be the only way for main to use a variable that is created in a different scope.
So my tip is; write your functions, and treat them as you usally should. Then when you are done, inline the short ones that you use a lot.
And if you really wanna create a variable in another function, allocate it on the heap in the function and return a pointer that you save and then set to 2 (your case). :) Just remember to free the memory!
You can do this, though:
#include <stdio.h>
int* GetMyIntAddress(void)
{
static int blah = 0;
return &blah;
}
int main(void)
{
printf("%d\n", *GetMyIntAddress());
*GetMyIntAddress() = 123;
printf("%d\n", *GetMyIntAddress());
return 0;
}
blah will be a global variable defined in the scope of the GetMyIntAddress() function.
If you add inline to the definition of GetMyIntAddress(), you are risking to get multiple independent instances of blah if the inline function is used in different modules (e.g. included from a shared header file).
I'm writing a piece of code where I have a function pointer that gets invoked. What I'd like to do is interpose on this function call to do something, and then invoke anotherfunction call with the same arguments. I wonder if there is some way to do this without having to write assembly for each architecture I'm targeting. Perhaps there are some GCC tricks?
As an example I call my function pointer and it invokes
foo (/*arguments*/) {
do_something...
bar(/*same arguments*/);
}
In assembly this is fairly easy. At least in x86 I just make sure that my stack pointer is reset to the beginning of my stack frame and jump to function bar (not call).
EDIT: Perhaps the example isn't clear. The user expects to be calling function bar but instead I have redirected it to function foo (I don't know what arguments bar takes). I want to do something in foo before calling bar with the same arguments that were passed on. In this way, whatever I'm doing in foo is transparent to the user who thinks they just called bar.
Have a look into gcc option -finstrument-functions.
Sounds like what the the gcc specific ___builtin_apply_args is for. It's an intristic that captures the passed in argument, and you can call another function with those arguments using __builtin_apply
libffi does all (or at least most) of what you need for source-level interposing.
Another option is to use dynamic binary instrumentation tools like DynamoRIO or Pin.
You could try creating a global function pointer variable that is used as a look-up for pre-binding the two function calls to one another. For instance,
typedef void (*bar_type)(int arg1, int arg2);
bar_type function_ptr; //a global function pointer used for binding
//create a bar_type function that is our "actual" function call
void __bar(int arg1, int arg2)
{
//do something else
}
//create a bar_type function called "foo" that is bound to calling whatever
//function is being pointed to by function_ptr
void foo(int arg1, int arg2)
{
//do something
function_ptr(arg1, arg2); //"foo" now calls "__bar"
}
bar_type transform_func(bar_type func_call, bar_type int_call)
{
function_ptr = func_call; //set the global function ptr variable
return int_call;
}
//create your function pointer bar that will call "foo" before calling "__bar"
bar_type bar = transform_func(__bar, foo);
//later on in your code
bar(3, 4); //this will call foo() which will then call __bar() internally
You could also with this approach create a macro that for the user where you could define bar as a macro that looks like
#define bar(arg1, arg2) (*(transform_func(__bar, foo)))(arg1, arg2);
Hopefully this isn't too kludgy ... there is definitely a performance hit from what could be done with assembly, but using the global function pointer would be a way to re-bind a function call.
Can you use a function-like macro to implement "do something" in the context of the calling function, and then do a normal call to the function pointer? (Yes, standard disclaimers about macros, esp. function-like macros apply...)
For example something like:
#define CALL_FUNC(fp,ARG1,ARG2) do {<do something>;fp(ARG1,ARG2);} while (0)
And then in the application, replace where you de-reference the function pointer with the macro.
It's not clear to me from the original question if foo or bar is the function called through the function pointer, so you might need to adjust the macro, but the general approach stays the same.
That may be really simple but I'm unable to find a good answer.
How can I make a macro representing first a certain value and then a different one?
I know that's nasty but I need it to implicitly declare a variable the first time and then do nothing.
This variable is required by other macros that I'm implementing.
Should I leverage "argument prescan"?
The thing you need to know is the fact I'm generating the code:
#define INC_X x++ //should be declared if needed to
#define PRINT_X printf("VALUE OF X: %d\n", x)
int func() {
[...]
INC_X;
[...]
INC_X;
[...]
PRINT_X;
[...]
}
As far as I know, this is impossible. I know of no way for the expansion of a macro to control the way another macro -- or itself -- will be expanded after. C99 introduced _Pragma so that #pragma things can be done in macros, but there is no equivalent for #define or #undef.
#include <stdio.h>
#define FOO &s[ (!c) ? (c++, 0) : (4) ]
static int c = 0;
const char s[] = { 'f', 'o', 'o', '\0', 'b', 'a', 'r', '\0' };
int main() {
puts(FOO);
puts(FOO);
return 0;
}
Does the above help?
From the look of it, you could try if Boost.Preprocessor contains what you are looking for.
Look at this tutorial
http://www.boostpro.com/tmpbook/preprocessor.html
from the excellent C++ Template Metaprogramming book.
With the edit, I'll have a go at an answer. It requires your compiler to support __FUNCTION__, which MSVC and GCC both do.
First, write a set of functions which maps strings to integers in memory, all stored in some global instance of a structure. This is left as an exercise for the reader, functionally it's a hashmap, but I'll call the resulting instance "global_x_map". The function get_int_ptr is defined to return a pointer to the int corresponding to the specified string, and if it doesn't already exist to create it and initialize it to 0. reset_int_ptr just assigns 0 to the counter for now, you'll see later why I didn't just write *_inc_x_tmp = 0;.
#define INC_X do {\
int *_inc_x_tmp = get_int_ptr(&global_x_map, __FILE__ "{}" __FUNCTION__); \
/* maybe some error-checking here, but not sure what you'd do about it */ \
++*_inc_x_tmp; \
} while(0)
#define PRINT_X do {\
int *_inc_x_tmp = get_int_ptr(&global_x_map, __FILE__ "{}" __FUNCTION__); \
printf("%d\n", *_inc_x_tmp); \
reset_int_ptr(&global_x_map, _inc_x_tmp); \
} while(0)
I've chose the separator "{}" on the basis that it won't occur in a mangled C function name - if your compiler for some reason might put that in a mangled function name then of course you'd have to change it. Using something which can't appear in a file name on your platform would also work.
Note that functions which use the macro are not re-entrant, so it is not quite the same as defining an automatic variable. I think it's possible to make it re-entrant, though. Pass __LINE__ as an extra parameter to get_int_ptr. When the entry is created, store the value of __LINE__.
Now, the map should store not just an int for each function, but a stack of ints. When it's called with that first-seen line value, it should push a new int onto the stack, and return a pointer to that int thereafter whenever it's called for that function with any other line value. When reset_int_ptr is called, instead of setting the counter to 0, it should pop the stack, so that future calls will return the previous int.
This only works of course if the "first" call to INC_X is always the same, is called only once per execution of the function, and that call doesn't appear on the same line as another call. If it's in a loop, if() block, etc, it goes wrong. But if it's inside a block, then declaring an automatic variable would go wrong too. It also only works if PRINT_X is always called (check your early error exits), otherwise you don't restore the stack.
This may all sound like a crazy amount of engineering, but essentially it is how Perl implements dynamically scoped variables: it has a stack for each symbol name. The difference is that like C++ with RAII, Perl automatically pops that stack on scope exit.
If you need it to be thread-safe as well as re-entrant, then make global_x_map thread-local instead of global.
Edit: That __FILE__ "{}" __FUNCTION__ identifier still isn't unique if you have static functions defined in header files - the different versions in different TUs will use the same counter in the non-re-entrant version. It's OK in the re-entrant version, though, I think. You'll also have problems if __FILE__ is a basename, not a full path, since you could get collisions for static functions of the same name defined in files of the same name. That scuppers even the re-entrant version. Finally, none of this is tested.
What about having the macro #define some flag at the end of it's execution and check for that flag first?
#def printFoo
#ifdef backagain
bar
#else
foo
#def backagain
Need to add some \ chars to make it work - and you probably don't want to actually do this compared to an inline func()
An alternative to some of the methods proposed thus far would be to use function pointers. It might not be quite what you are looking for, but they can still be a powerful tool.
void foo (void);
void bar (void);
void (*_func_foo)(void) = foo;
void foo (void) {
puts ("foo\n");
}
void bar (void) {
puts ("bar"\n");
}
#define FOO() _func_foo(); \
_func_foo = bar;
int main (void) {
FOO();
FOO();
FOO();
return 0;
}
#define FOO __COUNTER__ ? bar : foo
Edit: removed all unneeded code