Prevent incompatible function casts in C? - c

Question

Sometimes it is useful to cast function callbacks without.
For example, we may have a function to duplicate some data:
struct MyStruct *my_dupe_fn(const struct MyStruct *s)
But pass it as a generic callback:
typedef void *(*MyGenericCopyCallback)(void *key);
Eg: ensure_key_in_set(my_set, my_key, (MyGenericCopyCallback)my_dupe_fn);
Since the difference between const struct MyStruct * and void * is not going to cause problems in this case, it won't cause any bugs (at least in the function call its self).
However, if later on an arguments added to my_dupe_fn, this could cause a bug which wouldn't give a compiler warning.
Is there a way to cast a function, but still show warnings if the arguments or return values are different sizes?
Obligatory disclaimer: of course C isn't *safe*, but ways to prevent potential bugs in a widely used language are still useful.

Answer 1

You say "won't cause any bugs", however it causes undefined behaviour to call a function through a function pointer with incompatible return types or parameter types, even in your example code.
If you want to rely on undefined behaviour then that's your risk to take. Relying on UB has a tendency to cause bugs sooner or later. A better idea would be to re-design the callback interface to not rely on undefined behaviour. For example, only use functions of the correct type as the callback function.
In your example this might be:
typedef void *MyCallback(void *key); // style: avoid pointer typedefs
struct MyStruct *my_dupe_fn(const struct MyStruct *s)
{ ... }
void *my_dupe_fn_callback(void *s)
{
return my_dupe_fn(s);
}
void generic_algorithm(MyCallback *callback)
{
// ....
ensure_key_in_set(my_set, my_key, callback);
// ....
}
// elsewhere
generic_algorithm(my_dupe_fn_callback);
Note the lack of casts. Managing a style policy of not using any function casts is simpler than a policy of allowing certain types.

Answer 2

If you are using gcc and are not afraid of using helpful extensions, you might have a look at plan9-extensions. In combination with anonymous struct fields (standard since C99) as the first field, they allow to build a type-hierarchy with static functions, etc. Avoids tons of casts in my code and makes it much more readable.
Not sure, but according to the gcc documentation, the MS-compiler supports some (all?) these features, too. No warranty for that, however.

Answer 3

That later error is coming from two pieces of code that say the same thing getting out of sync -- the first where you define the type of my_dupe_fn, and the second where you cast the generic callback pointer back to its original type.
This is where DRY (do not repeat yourself) comes in. The whole point is to only say something once, so that you can't later come back and change only one instance.
In this case, you'd want to typedef the type of a pointer to my_dupe_fn, preferably very close to where you declare the function itself, to help ensure that the typedef always changes along with the function signiture itself.
The compiler is never going to catch this for you as long as it thinks that it is just dealing with a generic void pointer.

Answer 4

Unfortunately you typically have to forgo some of this compile-time safety if you're using C. You might get a warning at best, but if you have a design that is uniformly casting function pointers this way, you're likely to ignore or outright disable them. Instead you want to place your emphasis on achieving safe coding standards. What you can't guarantee by force, you can encourage strongly by policy.
I would suggest, if you can afford it, to start by casting arguments and return values rather than whole function pointers. A flexible representation is like so:
typedef void* GenericFunction(int argc, void** args);
This emulates the ability to have variadic callbacks, and you can uniformly do runtime safety checks in debug builds, e.g., to make sure that the number of arguments matches the assumptions:
void* MyCallback(int argc, void** args)
{
assert(argc == 2);
...
return 0;
}
If you need more safety than this for the individual arguments being passed and can afford a typically-small cost of an extra pointer per argument with a slightly bulky structured solution, you can do something like this:
struct Variant
{
void* ptr;
const char* type_name;
};
struct Variant to_variant(void* ptr, const char* type_name)
{
struct Variant new_var;
new_var.ptr = ptr;
new_var.type_name = type_name;
return new_var;
}
void* from_variant(struct Variant* var, const char* type_name)
{
assert(strcmp(var->type_name, type_name) == 0 && "Type mismatch!");
return var->ptr;
}
void* pop_variant(struct Variant** args, const char* type_name)
{
struct Variant* var = *args;
assert(var->ptr && "Trying to pop off the end of the argument stack!");
assert(strcmp(var->type_name, type_name) == 0 && "Type mismatch!");
++*args;
return var->ptr;
}
With macros like so:
#define TO_VARIANT(val, type) to_variant(&val, #type);
#define FROM_VARIANT(var, type) *(type*)from_variant(&var, #type);
#define POP_VARIANT(args, type) *(type*)pop_variant(&args, #type);
typedef struct Variant* GenericFunction(struct Variant* args);
Example callback:
struct Variant* MyCallback(struct Variant* args)
{
// `args` is null-terminated.
int arg1 = POP_VARIANT(args, int);
float arg2 = POP_VARIANT(args, float);
...
return 0;
}
A side benefit is what you can see in your debugger when you trace into MyCallback through those type_name fields.
This kind of thing can be useful if your codebase supports callbacks into dynamically-typed scripting languages, since scripting languages should not be doing type casts in their code (typically they're meant to be a bit on the safer side). The type names can then be used to automatically convert the arguments into the scripting language's native types dynamically using those type_name fields.