I've got a problem when the function is called by other functions.
My functions are so:
void *table_lookup(const table *t) {
...
//Here I want to call my other function.
table_remove(t);
...
}
void table_remove(table *t) {
...
}
I got a warning when I compile it. The problem is that I cannot change the argument's type.
You must NOT cast away the const qualifier. Any attempt to thereafter modify the value that was qualified const invokes Undefined Behavior. See C11 Standard - 6.7.3 Type qualifiers(p6).
The table_lookup parameter is const qualified for a reason. It allows the compiler to optimize the use of t. If you cast away the const and attempt to modify t you are breaking your promise to the compiler that t won't be modified.
Instead, you should refactor your code so that the remove() function calls table_lookup inside it to obtain a pointer (presumably) to the node you wish to remove. Then remove the node. Don't try and add a remove() within table_lookup. Create a new function.
In C, you can directly cast it to remove the 'const' property.
void *table_lookup(const table *t)
//Here I want to call my other function.
table_remove((table*)t) // remove 'const' by directly casting.
...
return
void table_remove(table *t)
...
You can cast away the const qualifier: table_remove((table *)t); but you might run into problems if table_remove tries to modify the table structure, for example if it is stored in a read-only segment.
Therefore you should not do it. It is rather unexpected that a lookup function would modify the table anyway. If it does for good reasons, such as building a hash table or maintaining a cache, the argument should not be declared as const.
Yes That’s right. it was bad idea to cast away const qualifier. . I can’t add a new function either. ((table)*) gives problem.
You can try the code below:
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wcast-qual"
void *table_lookup(const table *t) {
table_remove((table *)t);
}
#pragma GCC diagnostic pop
From: https://stackoverflow.com/a/13253997/5093308
Related
I have been reading about the restrict keyword and every example I've seen uses it when defining a function.
void foo (int *restrict bar, float *restrict baz);
I have been reading through articles on it and wondering if this would be something valid.
int main()
{
int *restrict bar = malloc(sizeof(int));
//... code using bar
return 0;
}
I tested it with gcc and I am not receiving any compiler warnings, but will it actually do anything? Will the compiler pick up that this pointer for it's life will not overlap and that it will not be shared by any other pointer or will it only work when used when defining a function?
The restricted 'bar' in main tell the compiler that the data will not be referenced via any other pointer. Depending on what main does, it might help with optimization of 'main'. If the only manipulation of bar is in function foo, there is no need to make it restrict.
As a side note, on Linux/gcc, the 'malloc' is tagged with __attribute__ ((__malloc__)), which tells the compiler that the returned value is restrict pointer, which will allow the compiler the perform the required optimization, if relevant. See: understanding malloc.h difference: __attribute_malloc__ https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
malloc
This tells the compiler that a function is malloc-like, i.e., that the pointer P
returned by the function cannot alias any other pointer valid when the function
returns, and moreover no pointers to valid objects occur in any storage addressed by P.
Using this attribute can improve optimization. Compiler predicts that
a function with the attribute returns non-null in most cases.
Functions like malloc and calloc have this property because they
return a pointer to uninitialized or zeroed-out storage. However,
functions like realloc do not have this property, as they can return a
pointer to storage containing pointers.
In my plain C99 project, I have an external C library that defines an interface (via GObject interfaces) that I need to implement:
void interface_function (const char *address, [...]);
Now, within the implementation (that I need to write) I need to call some other functions from a different library (so I can't change them) to which I need to pass *address, but their method signature omit the const keyword:
void some_api_function (char *address, [...]);
Now, if I simply pass *address down to some_api_function, I will get the compiler warning:
warning: passing argument 1 of ‘some_api_function’ discards ‘const’ qualifier from pointer target type [enabled by default]
I tried explicitly casting to char * in the function call like this:
`some_api_function ((char*) address, [...]) { ... }
but then I just get another warning:
warning: cast discards ‘__attribute__((const))’ qualifier from pointer target type [-Wcast-qual]
The problem is, that this is a larger C project with many people working on and policy is that -Werror is enabled and no code emitting warnings on compile is accepted into the mainline source code.
I can't change the interface definition because it is from a third party, and I can't change the API definitions of the external libraries, either. I know that *address is not modified in the external library (it could be const, but as I said I can't change that)
I also know that to solve this issue, I could just create a copy of the const char* into char *, but that doesn't feel right to me because it involves a unnecessary copy operation .
So what is the elegant or 'right' way to do this?
For absolute safety I'd deep copy the string and profile the performance impact. The author of the function makes no guarantee that they will not modify the string. If a parameter is marked const char* there is an implication that the string will not be changed by the function.
There are other choices; casting via (void*) or a clever union trick (see Gung Foo's answer), but neither will guarantee program stability.
You could use a union.
union charunion {
char *chr;
const char* cchr;
} chrptrs;
chrptrs.cchr; // const char *
chrptrs.chr; // char *
Warnings are there for a reason. As Bathseheeba says, the declaration makes no guarantee that the function will not modify the value, so if you know what you are doing -i.e. you know the function will not try to modify the value pointed by 'address'-, you can remove the warning by doing this:
void interface_function (const char *address, [...])
{
char *chrptr=(char *)address;
[...]
some_api_function (chrptr, [...]);
[...]
}
EDIT: I was answering before you commented that you were going with Bathsheeba's suggestion. Good choice.
I have a function pointer inside a struct that gets dynamically set at runtime to the address of another function in various places in my code. It is defined in my header file like this:
void *(*run)();
During compile time, I get the following warning about this:
warning: function declaration isn't a prototype
This warning is benign, because the pointer is used in many places in my code to call the function it points to, and everything works just fine. However, I would really like to silence the warning.
If I change it to this:
void *(*run)(void);
I get compile errors whever I use it, because the various functions that make use of the pointer have different numbers of arguments, and saying void inside the parenthesies tells the compiler it accepts no arguments.
I can't use a va_list or anything fancy like that, as this is simply a pointer to another function, and I use a single pointer for them all because it keeps the code clean and simple.
I can silence the warning with adding this to my compiler flags:
-Wno-strict-prototypes
But I'd rather not have to disable compiler warnings with flags if I can avoid it.
So my question is: How do I notate this function pointer in the code in such a way that the compiler is satisfied with the fact that it accepts any number of any kind of arguments?
The code works perfectly. I just want the warning to go away.
Store the pointer as a void * and cast to the appropriate function pointer type when necessary? Keep in mind that it isn't necessarily safe to call one type of function pointer as if it were another type, so the warning you're starting out with isn't entirely invalid.
You can cast a function pointer like so:
void *genericPointer = ...;
void (*fp)(int, int) = genericPointer;
fp(123, 456);
Note that:
There's no explicit casting necessary here, as void * can always be cast to any pointer type.
The initial "void" before (*fp) is the return type of the function pointer.
You are trying to do things clean - i.e. involve the compiler in checks, but the design you invented simply cannot be clean by its principle. You cannot involve compiler in prototype checks this way, because you always must know, which parameters to pass at this particular case in runtime. Compiler cannot check this and if you make a mistake, segmentation fault is on the way.
But if I remember well, something like this was maybe used also in linux kernel (?). The solution is to have a general pointer (like the one you have) and each time you call a particular function you just typecast it to the pointer to function with the particular arguments. You may need to typecast it to void * first to silence the compiler again :-)
In C, when you call a function without a prototype visible, default argument promotions are applied to all of the arguments that you pass to the function. This means that the types that you actually pass do not necessarily match the types received by the function.
E.g.
void (*g)();
void f()
{
float x = 0.5;
g(x); // double passed
}
This means that you need to know that the function that you are actually calling has a compatible signature to that implied by the arguments that you are passing after promotion.
Given that you need to know this in any case you must know the function signature of the actual function being called at the call site which is using the function pointer. With this knowledge it is usually simpler and cleaner to use a function pointer with the correct prototype and you can avoid default argument promotion entirely.
Note that as you are defining your functions with prototypes, when you assigned a pointer to your function to a function pointer without a prototype you effective converted, say, a void(*)(int, int) to a void(*)() so it is completely correct and desirable to perform the reverse conversion before calling the function. gcc allows both these conversions without emitting any warnings.
E.g.
void PerformCall( void(*p)() )
{
if (some_condition)
{
// due to extra knowledge I now know p takes two int arguments
// so use a function pointer with the correct prototype.
void(*prototyped_p)(int, int) = p;
prototyped_p( 3, 4 );
}
}
Try typedefing the function pointer declaration and then have the caller explicityly cast it:
typedef void *(*run)();
//when calling...
void my_foo() {}
run r = (run)my_foo;
If the different function signatures are known, use a union. Otherwise, use a pointer of type void (*)(void) (actually, any function pointer type would do) to hold the generic pointer and convert to the proper type when setting the value and calling the code.
Example using a union:
union run_fn
{
void *(*as_unary)(int);
void *(*as_binary)(int, int);
};
struct foo
{
union run_fn run;
};
void *bar(int, int);
struct foo foo;
foo.run.as_binary = bar;
void *baz = foo.run.as_binary(42, -1);
Example using explicit casts:
struct foo
{
void (*run)(void);
};
void *bar(int, int);
struct foo foo;
foo.run = (void *(*)(int, int))bar;
void *baz = ((void *(*)(int, int))foo.run)(42, -1);
Don't use a void * to hold function pointers - such a conversion is unspecified by the ISO C standard and may be unavailable on certain architectures.
Ignoring the warning and using your code as-is is actually also a possibility, but keep in mind that any function argument will be subject to the default argument promotions and it's your responsibility that the promoted arguments properly match the declared parameters.
I'm trying to check a C program with Splint (in strict mode). I annotated the source code with semantic comments to help Splint understand my program. Everything was fine, but I just can't get rid of a warning:
Statement has no effect (possible undected modification through call to unconstrained function my_function_pointer).
Statement has no visible effect --- no values are modified. It may modify something through a call to an unconstrained function. (Use -noeffectuncon to inhibit warning)
This is caused by a function call through a function pointer. I prefer not to use the no-effect-uncon flag, but rather write some more annotations to fix it up. So I decorated my typedef with the appropriate #modifies clause, but Splint seems to be completely ignoring it. The problem can be reduced to:
#include <stdio.h>
static void foo(int foobar)
/*#globals fileSystem#*/
/*#modifies fileSystem#*/
{
printf("foo: %d\n", foobar);
}
typedef void (*my_function_pointer_type)(int)
/*#globals fileSystem#*/
/*#modifies fileSystem#*/;
int main(/*#unused#*/ int argc, /*#unused#*/ char * argv[])
/*#globals fileSystem#*/
/*#modifies fileSystem#*/
{
my_function_pointer_type my_function_pointer = foo;
int foobar = 123;
printf("main: %d\n", foobar);
/* No warning */
/* foo(foobar); */
/* Warning: Statement has no effect */
my_function_pointer(foobar);
return(EXIT_SUCCESS);
}
I've read the manual, but there's not much information regarding function pointers and their semantic annotations, so I don't know whether I'm doing something wrong or this is some kind of bug (by the way, it's not already listed here: http://www.splint.org/bugs.html).
Has anyone managed to successfully check a program like this with Splint in strict mode? Please help me find the way to make Splint happy :)
Thanks in advance.
Update #1: splint-3.1.2 (windows version) yields the warning, while splint-3.1.1 (Linux x86 version) does not complain about it.
Update #2: Splint doesn't care whether the assignment and the call are short or long way:
/* assignment (short way) */
my_function_pointer_type my_function_pointer = foo;
/* assignment (long way) */
my_function_pointer_type my_function_pointer = &foo;
...
/* call (short way) */
my_function_pointer(foobar);
/* call (long way) */
(*my_function_pointer)(foobar);
Update #3: I'm not interested in inhibiting the warning. That's easy:
/*#-noeffectuncon#*/
my_function_pointer(foobar);
/*#=noeffectuncon#*/
What I'm looking for is the right way to express:
"this function pointer points to a function which #modifies stuff, so it does have side-effects"
Maybe you are confusing splint by relying on the implicit conversion from "function name" to "pointer to function" in your assignment of my_function_pointer. Instead, try the following:
// notice the &-character in front of foo
my_function_pointer_type my_function_pointer = &foo;
Now you have an explicit conversion and splint doesn't need to guess.
This is just speculation, though. I haven't tested it.
I'm not familiar with splint, but it looks to me that it will check function calls to see if they produce an effect, but it doesn't do analysis to see what a function pointer points to. Therefore, as far as it's concerned, a function pointer could be anything, and "anything" includes functions with no effect, and so you'll continue to get that warning on any use of a function pointer to call a function, unless you so something with the return value. The fact that there's not much on function pointers in the manual may mean they don't handle them properly.
Is there some sort of "trust me" annotation for an entire statement that you can use with function calls through pointers? It wouldn't be ideal, but it would allow you to get a clean run.
I believe the warning is correct. You're casting a value as a pointer but doing nothing with it.
A cast merely makes the value visible in a different manner; it doesn't change the value in any way. In this case you've told the compiler to view "foobar" as a pointer but since you're not doing anything with that view, the statement isn't doing anything (has no effect).
static void llist_dtor(void *user, void *element)
{
(void)user;
(void)element;
/* Do nothing */
}
Is it no-operation function? Then why is casting done? Is it ok to pass NULL as one of its parameters?
That's indeed a no-op. The casts to (void) are here to avoid getting "parameter never used" warnings with some compilers (the casts are optimized away, but the parameters are still considered as "used").
You can pass NULL since the parameters are ignored anyway.
Yes, this is a no-op function.
The casting is a common trick to prevent the compiler complaining about unused parameters.
Yes, this is a no-op function and void casted lines are placed to avoid the "unused parameter" warning. For gcc, search for "unused" in the page: http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
However, if it were C++ instead of C, I would probably write it little differently as
static void llist_dtor( void * /* user */, void * /* element */ )
{
/* Do nothing */
}
Note that the variable names are commented out.
That is not no-op. Like that you tell the compiler to ignore those two arguments.