Fixing `-Wincompatible-pointer-types` compiler warning

aha_1980

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 * with Foo * here. Any ideas how to fix this warning?

Thanks and regards

JonB

@aha_1980 said in Fixing `-Wincompatible-pointer-types` compiler warning:

I'm doing polymorphism in C

That's a new one on me! But never mind, I get the gist.

So you can see why the complaint. Your table demands functions which take a void * parameter but you are trying to set from a function which takes a Foo *.

To fix you must cast the actual function pointers to match the table's formal function definition. Create a convenient typedef TABLEFUNC for the int (*function)(void *) signature and

// edit: wrong ~~typedef int (*)(void *) TABLEFUNC;~~
typedef int (*TABLEFUNC)(void *);

const Table fooTable = {
	(TABLEFUNC) fooFunc,
	(TABLEFUNC) barFunc,
};

aha_1980

Hi @JonB,

yes that would work (it is typedef int (*TABLEFUNC)(void *) as definition, but otherwise alright.

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.

Except someone has an easier hint ;)

Thanks and regards

J.Hilk

@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 :(

aha_1980

@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 ;)

kshegunov

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 taking void *, 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.

JonB

@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 :)

@aha_1980

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. 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?
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 #pragma that warning off around the initialisations? Unless you regard that as worse, and do want code which actually passes the warning....

aha_1980

@kshegunov

Q: Why is the method taking void *, why not take directly an object pointer?

Because next to the fooTable, there is a barTable and a bazTable, each having its own type.

aha_1980

@JonB

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

@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 resolved vptr if 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 #pragma that 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;
};

aha_1980

@kshegunov I'll try that tomorrow. Sounds like a clever, reuseable, and clean macro solution :)

kshegunov

@aha_1980 said in Fixing `-Wincompatible-pointer-types` compiler warning:

and clean macro solution

As much as such a thing exists ;P

aha_1980

@kshegunov It doesn't - But in C it's the only possibility ;)

JonB

@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

@JonB

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 have Foo * 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

kshegunov

@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.

JonB

@aha_1980 said in Fixing `-Wincompatible-pointer-types` compiler warning:

So the "base class" has void * and the implementations have Foo * 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.

kshegunov

@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?

JonB

@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 what struct it is...?

kshegunov

@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 what struct it 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.