Fixing `-Wincompatible-pointer-types` compiler warning
-
I'm doing polymorphism in C (without ++, it's an embedded target where no C++ compiler is available).
All is working well so far, but when I compile the code with a recent GCC (for the unit tests), I have dozens of incompatible-pointer-types warnings which I'd like to fix (if possible).
The minimal example is as follows:
typedef struct Foo { int bar; } Foo; static int fooFunc(Foo *x) { return x->bar; } typedef struct Table { int (*function)(void *); } Table; const Table fooTable = { fooFunc // <- warning occurs here }; int main() { Foo f = {0}; return fooTable.function(&f); } //../main.c:14:2: warning: initialization of ‘int (*)(void *)’ // from incompatible pointer type ‘int (*)(Foo *)’ // [-Wincompatible-pointer-types] // 14 | fooFunc // | ^~~~~~~ //../main.c:14:2: note: (near initialization for ‘fooTable.function’)So in principle the compiler tells me, that I cannot mix
void *withFoo *here. Any ideas how to fix this warning?Thanks and regards
@aha_1980 what do you mean with
I have dozens of imcompatible-pointer-types warnings which I'd like to fix (if possible)Don't tell me you're not running with
-Werror😱
I would like to help, but I have no idea, sorry :(
Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct
Q: What's that?
A: It's blue light.
Q: What does it do?
A: It turns blue. -
@aha_1980 what do you mean with
I have dozens of imcompatible-pointer-types warnings which I'd like to fix (if possible)Don't tell me you're not running with
-Werror😱
I would like to help, but I have no idea, sorry :(
-
@J-Hilk the embedded compiler does not even complain about that.
And for gcc, I have to fix the ~100 warnings first before enabling such options ;)
You have to cast the pointers explicitly (as @JonB said). Ideally I'd do this with macro-magic, where I declare a table for a class with a macro, I start/end the table definition for a specific structure with a macro and define each of the entries with another. Also I'd do this at init time (just saying).
I have a question, though.
Q: Why is the method takingvoid *, why not take directly an object pointer?@JonB said in Fixing `-Wincompatible-pointer-types` compiler warning:
That's a new one on me!
C++ didn't invent this idea. It's as old as programming, more or less.
Read and abide by the Qt Code of Conduct
-
You have to cast the pointers explicitly (as @JonB said). Ideally I'd do this with macro-magic, where I declare a table for a class with a macro, I start/end the table definition for a specific structure with a macro and define each of the entries with another. Also I'd do this at init time (just saying).
I have a question, though.
Q: Why is the method takingvoid *, why not take directly an object pointer?@JonB said in Fixing `-Wincompatible-pointer-types` compiler warning:
That's a new one on me!
C++ didn't invent this idea. It's as old as programming, more or less.
@kshegunov said in Fixing `-Wincompatible-pointer-types` compiler warning:
C++ didn't invent this idea. It's as old as programming, more or less.
If you look around, you'll see as many references saying you cannot do polymorphism from C as those which say you can. with cheating-function-pointers :)
The only problem with that: the real table contains about 20 different TABLEFUNC definition, i.e. TABLEFUNC0, TABLEFUNC1, ... TABLEFUNC19). So a bit of work, but still manageable.
I don't understand. Thetypedef/macro is a single one for the type of the table elements, not the type(s) of the functions (which could vary) you put in it? So if you have one "the real table" I don't see why you want 20 typedefs?
EDIT From subsequent posts, here I realise I misunderstood. I thought you had an array of same-typed-function-pointers to which you wanted to assign various different actual functions. Looking carefully that does not correspond at all to the example code you gave, but it did apply to me when I had to do this in C during the last millennium... :)Except someone has an easier hint ;)
Since presumably you have just one table initialisation in one place (or maybe it's 20, not sure which), you could
#pragmathat warning off around the initialisations? Unless you regard that as worse, and do want code which actually passes the warning.... -
You have to cast the pointers explicitly (as @JonB said). Ideally I'd do this with macro-magic, where I declare a table for a class with a macro, I start/end the table definition for a specific structure with a macro and define each of the entries with another. Also I'd do this at init time (just saying).
I have a question, though.
Q: Why is the method takingvoid *, why not take directly an object pointer?@JonB said in Fixing `-Wincompatible-pointer-types` compiler warning:
That's a new one on me!
C++ didn't invent this idea. It's as old as programming, more or less.
Q: Why is the method taking void *, why not take directly an object pointer?
Because next to the
fooTable, there is abarTableand abazTable, each having its own type. -
@kshegunov said in Fixing `-Wincompatible-pointer-types` compiler warning:
C++ didn't invent this idea. It's as old as programming, more or less.
If you look around, you'll see as many references saying you cannot do polymorphism from C as those which say you can. with cheating-function-pointers :)
The only problem with that: the real table contains about 20 different TABLEFUNC definition, i.e. TABLEFUNC0, TABLEFUNC1, ... TABLEFUNC19). So a bit of work, but still manageable.
I don't understand. Thetypedef/macro is a single one for the type of the table elements, not the type(s) of the functions (which could vary) you put in it? So if you have one "the real table" I don't see why you want 20 typedefs?
EDIT From subsequent posts, here I realise I misunderstood. I thought you had an array of same-typed-function-pointers to which you wanted to assign various different actual functions. Looking carefully that does not correspond at all to the example code you gave, but it did apply to me when I had to do this in C during the last millennium... :)Except someone has an easier hint ;)
Since presumably you have just one table initialisation in one place (or maybe it's 20, not sure which), you could
#pragmathat warning off around the initialisations? Unless you regard that as worse, and do want code which actually passes the warning....I don't understand. The typedef/macro is a single one for the type of the table elements, not the type(s) of the functions (which could vary) you put in it? So if you have one "the real table" I don't see why you want 20 typedefs?
The real table looks like this:
typedef struct Table { bool init(void *); bool setParam1(void *, bool param); bool param1(void *); bool setParam2(void *, bool param); bool param2(void *); bool write(void *, uint32_t value); uint32_t read(void *, bool *ok); // ... } Table;So you need to have typedefs for each function prototype. Some might be reuseable, but probably it's better to have one for each row.
Since presumably you have just one table initialisation in one
No, I have a handful implementations of that.
@kshegunov idea of having a macro to create all the tables sounds great, I'll need to try that.
Thanks for your help
-
@kshegunov said in Fixing `-Wincompatible-pointer-types` compiler warning:
C++ didn't invent this idea. It's as old as programming, more or less.
If you look around, you'll see as many references saying you cannot do polymorphism from C as those which say you can. with cheating-function-pointers :)
The only problem with that: the real table contains about 20 different TABLEFUNC definition, i.e. TABLEFUNC0, TABLEFUNC1, ... TABLEFUNC19). So a bit of work, but still manageable.
I don't understand. Thetypedef/macro is a single one for the type of the table elements, not the type(s) of the functions (which could vary) you put in it? So if you have one "the real table" I don't see why you want 20 typedefs?
EDIT From subsequent posts, here I realise I misunderstood. I thought you had an array of same-typed-function-pointers to which you wanted to assign various different actual functions. Looking carefully that does not correspond at all to the example code you gave, but it did apply to me when I had to do this in C during the last millennium... :)Except someone has an easier hint ;)
Since presumably you have just one table initialisation in one place (or maybe it's 20, not sure which), you could
#pragmathat warning off around the initialisations? Unless you regard that as worse, and do want code which actually passes the warning....@JonB said in Fixing `-Wincompatible-pointer-types` compiler warning:
If you look around, you'll see as many references saying you cannot do polymorphism from C as those which say you can. with cheating-function-pointers :)
Nothing cheating about them. This is what the C++ compiler does under the hood, and it's been known from the "invention" of
virtual. It's a concept, it isn't some black magic, and the concept predates the language implementation. Try to use a virtual method in a class constructor and see how well it works before having a fully resolvedvptrif you don't believe me.I don't understand. The
typedef/macro is a single one for the type of the table elements, not the type(s) of the functions (which could vary) you put in it? So if you have one "the real table" I don't see why you want 20 typedefs?Functions may take a different set of arguments, I imagine.
Since presumably you have just one table initialisation in one place (or maybe it's 20, not sure which), you could
#pragmathat warning off around the initialisations? Unless you regard that as worse, and do want code which actually passes the warning....I personally would.
@aha_1980 said in Fixing `-Wincompatible-pointer-types` compiler warning:
Because next to the fooTable, there is a barTable and a bazTable, each having its own type.
Yeah, I think that's "more correct" approach.
Consider:BEGIN_VTABLE(ClassName) ADD_ENTRY(MethodName, int) END_VTABLE()expanding to something like:
struct ClassNameVTable { typedef ClassName Self; typedef (*MethodNameType)(Self *, int); // ... MethodNameType MethodName; };Read and abide by the Qt Code of Conduct
-
@JonB said in Fixing `-Wincompatible-pointer-types` compiler warning:
If you look around, you'll see as many references saying you cannot do polymorphism from C as those which say you can. with cheating-function-pointers :)
Nothing cheating about them. This is what the C++ compiler does under the hood, and it's been known from the "invention" of
virtual. It's a concept, it isn't some black magic, and the concept predates the language implementation. Try to use a virtual method in a class constructor and see how well it works before having a fully resolvedvptrif you don't believe me.I don't understand. The
typedef/macro is a single one for the type of the table elements, not the type(s) of the functions (which could vary) you put in it? So if you have one "the real table" I don't see why you want 20 typedefs?Functions may take a different set of arguments, I imagine.
Since presumably you have just one table initialisation in one place (or maybe it's 20, not sure which), you could
#pragmathat warning off around the initialisations? Unless you regard that as worse, and do want code which actually passes the warning....I personally would.
@aha_1980 said in Fixing `-Wincompatible-pointer-types` compiler warning:
Because next to the fooTable, there is a barTable and a bazTable, each having its own type.
Yeah, I think that's "more correct" approach.
Consider:BEGIN_VTABLE(ClassName) ADD_ENTRY(MethodName, int) END_VTABLE()expanding to something like:
struct ClassNameVTable { typedef ClassName Self; typedef (*MethodNameType)(Self *, int); // ... MethodNameType MethodName; };@kshegunov I'll try that tomorrow. Sounds like a clever, reuseable, and clean macro solution :)
Qt has to stay free or it will die.
-
@kshegunov I'll try that tomorrow. Sounds like a clever, reuseable, and clean macro solution :)
@aha_1980 said in Fixing `-Wincompatible-pointer-types` compiler warning:
and clean macro solution
As much as such a thing exists ;P
Read and abide by the Qt Code of Conduct
-
@aha_1980 said in Fixing `-Wincompatible-pointer-types` compiler warning:
and clean macro solution
As much as such a thing exists ;P
@kshegunov It doesn't - But in C it's the only possibility ;)
-
I don't understand. The typedef/macro is a single one for the type of the table elements, not the type(s) of the functions (which could vary) you put in it? So if you have one "the real table" I don't see why you want 20 typedefs?
The real table looks like this:
typedef struct Table { bool init(void *); bool setParam1(void *, bool param); bool param1(void *); bool setParam2(void *, bool param); bool param2(void *); bool write(void *, uint32_t value); uint32_t read(void *, bool *ok); // ... } Table;So you need to have typedefs for each function prototype. Some might be reuseable, but probably it's better to have one for each row.
Since presumably you have just one table initialisation in one
No, I have a handful implementations of that.
@kshegunov idea of having a macro to create all the tables sounds great, I'll need to try that.
Thanks for your help
@aha_1980 said in Fixing `-Wincompatible-pointer-types` compiler warning:
The real table looks like this:
Yes, sorry, I edited my earlier post, I quite misunderstood and thought you had an array of function pointers to which you wanted to assign.
But now there is something odd in your case. Since you have
The real table looks like this:
typedef struct Table { bool init(void *); bool setParam1(void *, bool param);that implies you are writing out exactly the required signature for each function pointer in the
struct. In which case, why don't they match correctly against the functions you are assigning to them, then you wouldn't need casts...? That is why I was thinking of the array-of-function-pointers situation, where you do have a problem with one array element type and mutiple different function types to assign. -
@aha_1980 said in Fixing `-Wincompatible-pointer-types` compiler warning:
The real table looks like this:
Yes, sorry, I edited my earlier post, I quite misunderstood and thought you had an array of function pointers to which you wanted to assign.
But now there is something odd in your case. Since you have
The real table looks like this:
typedef struct Table { bool init(void *); bool setParam1(void *, bool param);that implies you are writing out exactly the required signature for each function pointer in the
struct. In which case, why don't they match correctly against the functions you are assigning to them, then you wouldn't need casts...? That is why I was thinking of the array-of-function-pointers situation, where you do have a problem with one array element type and mutiple different function types to assign.As @kshegunov already wrote, the first pointer, the
void *is specialized for each implementation struct - think of inheritance.So the "base class" has
void *and the implementations haveFoo *resp.Bar *.Nothing wrong with that, just that the compiler warns at this point (which is a bit pointless imho, as ever pointer is compatible to
void *, but ok.Regards
Qt has to stay free or it will die.
-
As @kshegunov already wrote, the first pointer, the
void *is specialized for each implementation struct - think of inheritance.So the "base class" has
void *and the implementations haveFoo *resp.Bar *.Nothing wrong with that, just that the compiler warns at this point (which is a bit pointless imho, as ever pointer is compatible to
void *, but ok.Regards
@aha_1980 said in Fixing `-Wincompatible-pointer-types` compiler warning:
Nothing wrong with that, just that the compiler warns at this point (which is a bit pointless imho, as ever pointer is compatible to void *, but ok.
Yes, every pointer decays implicitly to
void *, but that's not what the compiler whines about. It complains because the function prototypes are different, hence the actual functions may be different, the compiler can't tell out of the box. -
As @kshegunov already wrote, the first pointer, the
void *is specialized for each implementation struct - think of inheritance.So the "base class" has
void *and the implementations haveFoo *resp.Bar *.Nothing wrong with that, just that the compiler warns at this point (which is a bit pointless imho, as ever pointer is compatible to
void *, but ok.Regards
@aha_1980 said in Fixing `-Wincompatible-pointer-types` compiler warning:
So the "base class" has
void *and the implementations haveFoo *resp.Bar *.What I don't get is: if these classes do not share some base class (
Foo,Bar, or something else), it's a bit hard to think what you're doing in C++ to either of them as a parameter to a function when all they have in common is they are pointers to something unknown?You don't have to answer/justify yourself. I realise you doubtless know what you are doing and have your own reasons. But that's what strikes me.
-
@aha_1980 said in Fixing `-Wincompatible-pointer-types` compiler warning:
So the "base class" has
void *and the implementations haveFoo *resp.Bar *.What I don't get is: if these classes do not share some base class (
Foo,Bar, or something else), it's a bit hard to think what you're doing in C++ to either of them as a parameter to a function when all they have in common is they are pointers to something unknown?You don't have to answer/justify yourself. I realise you doubtless know what you are doing and have your own reasons. But that's what strikes me.
@JonB said in Fixing `-Wincompatible-pointer-types` compiler warning:
What I don't get is: if these classes do not share some base class (Foo, Bar, or something else), it's a bit hard to think what you're doing in C++ to either of them as a parameter to a function when all they have in common is they are pointers to something unknown?
What is a base class in C?
Read and abide by the Qt Code of Conduct
-
@JonB said in Fixing `-Wincompatible-pointer-types` compiler warning:
What I don't get is: if these classes do not share some base class (Foo, Bar, or something else), it's a bit hard to think what you're doing in C++ to either of them as a parameter to a function when all they have in common is they are pointers to something unknown?
What is a base class in C?
@kshegunov said in Fixing `-Wincompatible-pointer-types` compiler warning:
What is a base class in C?
Oh damn! I forgot already this is not C++, sorry... !
OK, well, I still wonder what the shared function does being handed pointers to different C
structs, when you don't know whatstructit is...? -
@kshegunov said in Fixing `-Wincompatible-pointer-types` compiler warning:
What is a base class in C?
Oh damn! I forgot already this is not C++, sorry... !
OK, well, I still wonder what the shared function does being handed pointers to different C
structs, when you don't know whatstructit is...?@JonB said in Fixing `-Wincompatible-pointer-types` compiler warning:
OK, well, I still wonder what the shared function does being handed pointers to different C
structs, when you don't know whatstructit is...?Well, as far as I understood the task the point is to allow inheritance support for a language (and a compiler) which doesn't provide it. This entails (if you follow what C++ does) having a static table of methods for each "class". Each "inherited" table then is supposedly referencing the base class' table and further allowing it to be extended. And if you want at the end you can get dynamic polymorphism in. All in all it's not a trivial thing to do, but should be doable with some magic.
-
@fcarney said in Fixing `-Wincompatible-pointer-types` compiler warning:
Makes me wonder if there is a C++ "like" preprocessor that can produce C.
cmake can produce code (even source I think), and of course you can write your own preprocessor if you wish ... :D
