There is an old third-party library where some function pointers are
casted to another type, then back to the original type before use. C++
standard says this is kosher, and there have never been any problems
with actual behavior. Alas, different versions and compile modes of g++
still produce warnings. What would be the best way to silence them
(without just switching off warnings)?

Simplified example:

typedef double (*Func)(double);
typedef double (*DoubleFunc_2_args)(double, double);

Func FuncCast2(DoubleFunc_2_args fp) {
return reinterpret_cast<Func>(fp);
}

$ g++ test1.cpp -Wall -Wextra
test1.cpp: In function ‘double (* FuncCast2(DoubleFunc_2_args))(double)’:
test1.cpp:26:34: warning: cast between incompatible function types from
‘DoubleFunc_2_args’ {aka ‘double (*)(double, double)’} to ‘Func’ {aka
‘double (*)(double)’} [-Wcast-function-type]
return reinterpret_cast<Func>(fp);

If I change the function to use more indirection, then there is a
warning with -O2 only:

Func FuncCast2(DoubleFunc_2_args fp) {
return *reinterpret_cast<Func*>(&fp);
}

$ g++ test1.cpp -Wall -Wextra -O2
test1.cpp: In function ‘double (* FuncCast2(DoubleFunc_2_args))(double)’:
test1.cpp:22:10: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
return *reinterpret_cast<Func*>(&fp);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~

$ g++ --version
g++ (Debian 10.2.1-6) 10.2.1 20210110

Am 23.04.2024 um 13:31 schrieb Paavo Helde:
>
> There is an old third-party library where some function pointers are
> casted to another type, then back to the original type before use.
> C++ standard says this is kosher, and there have never been any
> problems with actual behavior. Alas, different versions and compile
> modes of g++ still produce warnings. ...

That's because of the danger that someone calls the function-pointer
to which you cast. Maybe you can cast through a void-pointer to sup-
press this warning. But for me casting to a function pointer of a
differnt type doesn't make sense at at..
I think you confront yourself to uncertainties which actually never
happen.

Am 23.04.24 um 13:31 schrieb Paavo Helde:
>
> There is an old third-party library where some function pointers are
> casted to another type, then back to the original type before use. C++
> standard says this is kosher, and there have never been any problems
> with actual behavior. Alas, different versions and compile modes of g++
> still produce warnings. What would be the best way to silence them
> (without just switching off warnings)?

You could use a union, if you know all possible function types
beforehand.

> typedef double (*Func)(double);
> typedef double (*DoubleFunc_2_args)(double, double);
>
> Func FuncCast2(DoubleFunc_2_args fp) {
> return reinterpret_cast<Func>(fp);
> }
>
> $ g++ test1.cpp -Wall -Wextra
> test1.cpp: In function ‘double (* FuncCast2(DoubleFunc_2_args))(double)’:
> test1.cpp:26:34: warning: cast between incompatible function types from
> ‘DoubleFunc_2_args’ {aka ‘double (*)(double, double)’} to ‘Func’ {aka
> ‘double (*)(double)’} [-Wcast-function-type]
> return reinterpret_cast<Func>(fp);

You could wonder why you are asking for non-standard (extra)
warnings in the first place.

Out of curiosity I have fiddled with g++, asking myself if there
is a type like (void*) for objects, that the compiler is happy
converting function pointers into. And alas, there is! And it is
the type one would guess:

typedef void (*UniversalFunctionPointer)();

Of course it's a cat-and-mouse play with these compiler warnings.

BR

On 23/04/2024 13:31, Paavo Helde wrote:
>
> There is an old third-party library where some function pointers are
> casted to another type, then back to the original type before use. C++
> standard says this is kosher, and there have never been any problems
> with actual behavior. Alas, different versions and compile modes of g++
> still produce warnings. What would be the best way to silence them
> (without just switching off warnings)?
>
>
> Simplified example:
>
> typedef double (*Func)(double);
> typedef double (*DoubleFunc_2_args)(double, double);
>
> Func FuncCast2(DoubleFunc_2_args fp) {
>     return reinterpret_cast<Func>(fp);
> }
>
> $ g++ test1.cpp -Wall -Wextra
> test1.cpp: In function ‘double (* FuncCast2(DoubleFunc_2_args))(double)’:
> test1.cpp:26:34: warning: cast between incompatible function types from
> ‘DoubleFunc_2_args’ {aka ‘double (*)(double, double)’} to ‘Func’ {aka
> ‘double (*)(double)’} [-Wcast-function-type]
>   return reinterpret_cast<Func>(fp);
>
>
> If I change the function to use more indirection, then there is a
> warning with -O2 only:
>
> Func FuncCast2(DoubleFunc_2_args fp) {
>     return *reinterpret_cast<Func*>(&fp);
> }
>
> $ g++ test1.cpp -Wall -Wextra -O2
> test1.cpp: In function ‘double (* FuncCast2(DoubleFunc_2_args))(double)’:
> test1.cpp:22:10: warning: dereferencing type-punned pointer will break
> strict-aliasing rules [-Wstrict-aliasing]
>   return *reinterpret_cast<Func*>(&fp);
>           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> $ g++ --version
> g++ (Debian 10.2.1-6) 10.2.1 20210110

The compiler is warning here about casting incompatible function types
because usually such casts are a bad idea. In particular, casting to a
different function type, then calling through this new type, is
undefined behaviour. About the only useful thing you can do with your
cast pointer is cast it back to the original type before calling it. So
g++ with -Wextra warns you that you have either made a mistake in your
code, or are trying to do something that is potentially dangerous.

The compiler then helpfully tells you exactly why you got the warning,
and makes it obvious what you can do to hide the warning, by giving you
the specific flag - "-Wcast-function-type". You disable that warning by
using "-Wno-cast-function-type", or by using the appropriate pragma:

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wcast-function-type"
inline Func FuncCast2(DoubleFunc_2_args fp) {
return reinterpret_cast<Func>(fp);
} #pragma GCC diagnostic pop

On 23/04/2024 14:23, Markus Schaaf wrote:
> Am 23.04.24 um 13:31 schrieb Paavo Helde:
>>
>> There is an old third-party library where some function pointers are
>> casted to another type, then back to the original type before use. C++
>> standard says this is kosher, and there have never been any problems
>> with actual behavior. Alas, different versions and compile modes of g++
>> still produce warnings. What would be the best way to silence them
>> (without just switching off warnings)?
>
> You could use a union, if you know all possible function types beforehand.
>

You /could/, if you don't mind the undefined behaviour - type-punning
unions are not defined behaviour in C++.

>> typedef double (*Func)(double);
>> typedef double (*DoubleFunc_2_args)(double, double);
>>
>> Func FuncCast2(DoubleFunc_2_args fp) {
>>     return reinterpret_cast<Func>(fp);
>> }
>>
>> $ g++ test1.cpp -Wall -Wextra
>> test1.cpp: In function ‘double (* FuncCast2(DoubleFunc_2_args))(double)’:
>> test1.cpp:26:34: warning: cast between incompatible function types from
>> ‘DoubleFunc_2_args’ {aka ‘double (*)(double, double)’} to ‘Func’ {aka
>> ‘double (*)(double)’} [-Wcast-function-type]
>>     return reinterpret_cast<Func>(fp);
>
> You could wonder why you are asking for non-standard (extra) warnings in
> the first place.
>

I can't answer for the OP, but I know why /I/ use lots of extra warnings
in my code. (What do you mean by "non-standard warnings" anyway? There
are standards-required diagnostics, but AFAIK the standard does not
distinguish between errors and warnings, except for #error directives.)

Am 23.04.24 um 16:44 schrieb David Brown:
> On 23/04/2024 14:23, Markus Schaaf wrote:
>> Am 23.04.24 um 13:31 schrieb Paavo Helde:
>>>
>>> There is an old third-party library where some function pointers are
>>> casted to another type, then back to the original type before use. C++
>>> standard says this is kosher, and there have never been any problems
>>> with actual behavior. Alas, different versions and compile modes of g++
>>> still produce warnings. What would be the best way to silence them
>>> (without just switching off warnings)?
>>
>> You could use a union, if you know all possible function types beforehand.
>>
>
> You /could/, if you don't mind the undefined behaviour - type-punning
> unions are not defined behaviour in C++.

I have no idea what you are writing about. Of course one would
read the exact same member of the union one had written to
before. That is what unions are for.

BR

23.04.2024 14:44 Bonita Montero kirjutas:
> Am 23.04.2024 um 13:31 schrieb Paavo Helde:
>>
>> There is an old third-party library where some function pointers are
>> casted to another type, then back to the original type before use.
>> C++  standard says this is kosher, and there have never been any
>> problems  with actual behavior. Alas, different versions and compile
>> modes of g++ still produce warnings. ...
>
> That's because of the danger that someone calls the function-pointer
> to which you cast. Maybe you can cast through a void-pointer to sup-
> press this warning. But for me casting to a function pointer of a
> differnt type doesn't make sense at at..
> I think you confront yourself to uncertainties which actually never
> happen.
>

The function pointers are cast to a single type so that they can be
stored in a common lookup array. I could use a union there, but this
would mean additional work with no real benefit, as the hypothetical
"someone" could just as easily mess up the unions than the casting.

23.04.2024 15:23 Markus Schaaf kirjutas:
> Am 23.04.24 um 13:31 schrieb Paavo Helde:
>>
>> There is an old third-party library where some function pointers are
>> casted to another type, then back to the original type before use. C++
>> standard says this is kosher, and there have never been any problems
>> with actual behavior. Alas, different versions and compile modes of g++
>> still produce warnings. What would be the best way to silence them
>> (without just switching off warnings)?
>
> You could use a union, if you know all possible function types beforehand.

Right, I could use union, it's just extra work and some danger of
introducing new bugs in this old third-party code.

>
>> typedef double (*Func)(double);
>> typedef double (*DoubleFunc_2_args)(double, double);
>>
>> Func FuncCast2(DoubleFunc_2_args fp) {
>>     return reinterpret_cast<Func>(fp);
>> }
>>
>> $ g++ test1.cpp -Wall -Wextra
>> test1.cpp: In function ‘double (* FuncCast2(DoubleFunc_2_args))(double)’:
>> test1.cpp:26:34: warning: cast between incompatible function types from
>> ‘DoubleFunc_2_args’ {aka ‘double (*)(double, double)’} to ‘Func’ {aka
>> ‘double (*)(double)’} [-Wcast-function-type]
>>     return reinterpret_cast<Func>(fp);
>
> You could wonder why you are asking for non-standard (extra) warnings in
> the first place.

Because using -Wall -Wextra (and sometimes more) has been encouraged by
people in this group and elsewhere.

I suspect -Wcast-function-type has been added into -Wextra during some
last 10 years, I'm pretty sure earlier this code used to compile without
warnings, it has been relatively recently when this has started to
irritate me (mostly because we have managed to get the rest of the
codebase almost warning-free ;-).

>
> Out of curiosity I have fiddled with g++, asking myself if there is a
> type like (void*) for objects, that the compiler is happy converting
> function pointers into. And alas, there is! And it is the type one would
> guess:
>
> typedef void (*UniversalFunctionPointer)();

Adding an intermediate reinterpret_cast to this type indeed seems to get
rid of the warning! Thanks a lot!

Am 23.04.24 um 20:50 schrieb Paavo Helde:

>> typedef void (*UniversalFunctionPointer)();
>
> Adding an intermediate reinterpret_cast to this type indeed seems to get
> rid of the warning! Thanks a lot!

Wouldn't it be better to change the storage type of these
function pointers in your registry to above type, making the
intention clear to those you recognize its special property?
Instead of introducing obscure cast chains everywhere.

BR

Am 23.04.24 um 22:18 schrieb Markus Schaaf:

> intention clear to those you recognize its special property?

.... to those who recognize ...

(Phonetic typing error, interesting.)

BR

23.04.2024 23:18 Markus Schaaf kirjutas:
> Am 23.04.24 um 20:50 schrieb Paavo Helde:
>
>>> typedef void (*UniversalFunctionPointer)();
>>
>> Adding an intermediate reinterpret_cast to this type indeed seems to get
>> rid of the warning! Thanks a lot!
>
> Wouldn't it be better to change the storage type of these function
> pointers in your registry to above type, making the intention clear to
> those you recognize its special property? Instead of introducing obscure
> cast chains everywhere.

Yes, it would be better or at least more symmetric, assuming that
somebody will read this third-party code some day. This has not happened
in the last 20 years, but you never know. I will think about that.

BR

On 23/04/2024 20:33, Paavo Helde wrote:
> 23.04.2024 14:44 Bonita Montero kirjutas:
>> Am 23.04.2024 um 13:31 schrieb Paavo Helde:
>>>
>>> There is an old third-party library where some function pointers are
>>> casted to another type, then back to the original type before use.
>>> C++  standard says this is kosher, and there have never been any
>>> problems  with actual behavior. Alas, different versions and compile
>>> modes of g++ still produce warnings. ...
>>
>> That's because of the danger that someone calls the function-pointer
>> to which you cast. Maybe you can cast through a void-pointer to sup-
>> press this warning. But for me casting to a function pointer of a
>> differnt type doesn't make sense at at..
>> I think you confront yourself to uncertainties which actually never
>> happen.
>>
>
> The function pointers are cast to a single type so that they can be
> stored in a common lookup array. I could use a union there, but this
> would mean additional work with no real benefit, as the hypothetical
> "someone" could just as easily mess up the unions than the casting.

You could consider using std::variant<>, but you need to know the
possible function types in advance (that may or may not be an issue for
you) and it stores an index to in the variant object. Again, that may
or may not be a useful thing for you.

Otherwise I agree with you that casting to a common "void (*)(void)"
pointer type seems reasonable here. Just disable the warning around the
casts.

Am 23.04.2024 um 20:33 schrieb Paavo Helde:

> The function pointers are cast to a single type so that they can be
> stored in a common lookup array. ...

Then you'd need additional information to distinguish the different
types. If you have sth. like that you could take a variant<>.

On 23/04/2024 17:00, Markus Schaaf wrote:
> Am 23.04.24 um 16:44 schrieb David Brown:
>> On 23/04/2024 14:23, Markus Schaaf wrote:
>>> Am 23.04.24 um 13:31 schrieb Paavo Helde:
>>>>
>>>> There is an old third-party library where some function pointers are
>>>> casted to another type, then back to the original type before use. C++
>>>> standard says this is kosher, and there have never been any problems
>>>> with actual behavior. Alas, different versions and compile modes of g++
>>>> still produce warnings. What would be the best way to silence them
>>>> (without just switching off warnings)?
>>>
>>> You could use a union, if you know all possible function types
>>> beforehand.
>>>
>>
>> You /could/, if you don't mind the undefined behaviour - type-punning
>> unions are not defined behaviour in C++.
>
> I have no idea what you are writing about. Of course one would read the
> exact same member of the union one had written to before. That is what
> unions are for.
>
> BR

Type-punning unions are defined behaviour in C, undefined in C++. A
typical example (written to be compilable as C and C++) would be :

typedef union RawFloat {
float f;
unsigned int u;
} RawFloat;

unsigned int float_to_raw(float f) {
RawFloat r;
r.f = f;
return r.u;
}

In C, writing to one union member and then reading via a different union
member is defined behaviour - you get the same underlying
representation, re-interpreted as the new type. This is known as "type
punning", and was explicitly given defined behaviour in C99. (Prior to
C99, the standard was vague on the topic.)

In C++, this is undefined behaviour - you may not read a union member
that was not the last written member.

Many - perhaps most - C++ compilers allow type-punning via unions in
C++, as long as they are standard layout unions (simple types with no
constructors, virtual functions, or anything beyond plain C). But this
is not defined behaviour according to the C++ standards. In C++, the
defined ways to achieve type punning are std::memcpy and std::bit_cast<>
(in C++20).

Unions were /not/ intended for type-punning. They were designed for
saving memory and to support "sum" types (compared to structs which are
"product" types). But they are also sometimes used for type-punning,
and the definition of this behaviour was added to C99 because some
people non-portably relied on that behaviour in existing C code. It was
/not/ added to C++ because specifying such a rule would be complicated
in the face of more advanced types.

<https://en.cppreference.com/w/c/language/union>
(See the first "since C99" box)

<https://en.cppreference.com/w/cpp/language/union>
(See the first paragraph of "Explanation")

Am 23.04.2024 um 16:44 schrieb David Brown:

> The compiler is warning here about casting incompatible function types
> because usually such casts are a bad idea.  In particular, casting to
> a different function type, then calling through this new type, is
> undefined behaviour.  About the only useful thing you can do with your
> cast pointer is cast it back to the original type before calling it.
> So g++ with -Wextra warns you that you have either made a mistake in
> your code, or are trying to do something that is potentially dangerous.

He needs to store different function-pointers with a common type;
why not as a void-pointer ?

Am 23.04.2024 um 16:44 schrieb David Brown:

> You /could/, if you don't mind the undefined behaviour - type-punning
> unions are not defined behaviour in C++.

Actually all compiler support that. But MSVC++ isn't that efficient
with that like clang or g++; MSVC often does a store and load round-
trip. But there's bit_cast with C++20, which also works efficient
with MSVC++. But actually he neither needs bit_cast nor unions for
his purpose, but just a reinterpret_cast or a C-style cast, which
I prefer for readability.

Am 23.04.2024 um 17:00 schrieb Markus Schaaf:
> Am 23.04.24 um 16:44 schrieb David Brown:
>> On 23/04/2024 14:23, Markus Schaaf wrote:
>>> Am 23.04.24 um 13:31 schrieb Paavo Helde:
>>>>
>>>> There is an old third-party library where some function pointers are
>>>> casted to another type, then back to the original type before use. C++
>>>> standard says this is kosher, and there have never been any problems
>>>> with actual behavior. Alas, different versions and compile modes of g++
>>>> still produce warnings. What would be the best way to silence them
>>>> (without just switching off warnings)?
>>>
>>> You could use a union, if you know all possible function types
>>> beforehand.
>>>
>>
>> You /could/, if you don't mind the undefined behaviour - type-punning
>> unions are not defined behaviour in C++.
>
> I have no idea what you are writing about. Of course one would read the
> exact same member of the union one had written to before. That is what
> unions are for.

A union actually isn't needed for the discusses purpose.
Just do a reinterpret_cast or a C-style cast.

On 24/04/2024 11:27, Bonita Montero wrote:
> Am 23.04.2024 um 16:44 schrieb David Brown:
>
>> The compiler is warning here about casting incompatible function types
>> because usually such casts are a bad idea.  In particular, casting to
>> a  different function type, then calling through this new type, is
>> undefined behaviour.  About the only useful thing you can do with your
>> cast pointer is cast it back to the original type before calling it.
>> So  g++ with -Wextra warns you that you have either made a mistake in
>> your code, or are trying to do something that is potentially dangerous.
>
> He needs to store different function-pointers with a common type;
> why not as a void-pointer ?

As far as I know, the standards do not define the behaviour of casting
between function pointers and void pointers (or any object pointers).
The C standards are clear about the matter - it is not defined
behaviour. But I don't know the C++ standards well enough to say.

For C, you can happily use "void (*)(void)" as a universal function
pointer type, rather than "* void" which is only for object pointers.

The compiler warning here is a good idea for most code, but sometimes
you need code that is potentially risky but you know is correct - such
as converting function pointer types before storing them, and converting
them back before using them. The OP just needs to disable the warning
around the code that does this conversion.

On 24/04/2024 13:11, Bonita Montero wrote:
> Am 23.04.2024 um 17:00 schrieb Markus Schaaf:
>> Am 23.04.24 um 16:44 schrieb David Brown:
>>> On 23/04/2024 14:23, Markus Schaaf wrote:
>>>> Am 23.04.24 um 13:31 schrieb Paavo Helde:
>>>>>
>>>>> There is an old third-party library where some function pointers are
>>>>> casted to another type, then back to the original type before use. C++
>>>>> standard says this is kosher, and there have never been any problems
>>>>> with actual behavior. Alas, different versions and compile modes of
>>>>> g++
>>>>> still produce warnings. What would be the best way to silence them
>>>>> (without just switching off warnings)?
>>>>
>>>> You could use a union, if you know all possible function types
>>>> beforehand.
>>>>
>>>
>>> You /could/, if you don't mind the undefined behaviour - type-punning
>>> unions are not defined behaviour in C++.
>>
>> I have no idea what you are writing about. Of course one would read
>> the exact same member of the union one had written to before. That is
>> what unions are for.
>
> A union actually isn't needed for the discusses purpose.
> Just do a reinterpret_cast or a C-style cast.
>

Sure - that's what the OP is doing. It's not the cast that is his
problem - it is the compiler warning that he'd like to avoid.

On 24/04/2024 13:10, Bonita Montero wrote:
> Am 23.04.2024 um 16:44 schrieb David Brown:
>
>> You /could/, if you don't mind the undefined behaviour - type-punning
>> unions are not defined behaviour in C++.
>
> Actually all compiler support that.

That may be true - but I am entirely confident that you don't know it is
true. You live in a little world where the only compiler is MSVC++ -
you know nothing about the hundred other C++ compilers out there. (I
know more of them than you - and more importantly, I know my knowledge
is limited.)

Compiler extensions can be useful - and sometimes essential. It's fine
to write non-portable code when you have to do so. It is a much worse
idea to use non-portable code when it is needless to do so. There's no
need to use type-punning unions in C++, so don't do it - even if it
happens to work on the compilers you tested.

> But MSVC++ isn't that efficient
> with that like clang or g++; MSVC often does a store and load round-
> trip. But there's bit_cast with C++20, which also works efficient
> with MSVC++.

Yes, std::bit_cast<> is (as I said) a good and well-defined alternative
to type-punning unions in C++20. And if you have to use a poor-quality
compiler that can't do a decent job of optimising memcpy, then it's
definitely the way to go for general type-punning uses.

> But actually he neither needs bit_cast nor unions for
> his purpose, but just a reinterpret_cast or a C-style cast, which
> I prefer for readability.
>

Agreed, in this particular case - and reinterpret_cast<> was the OP's
original choice.

On 2024-04-24 at 13:14, David Brown wrote:
> On 24/04/2024 11:27, Bonita Montero wrote:
>> Am 23.04.2024 um 16:44 schrieb David Brown:
>>
>>> The compiler is warning here about casting incompatible function
>>> types because usually such casts are a bad idea.  In particular,
>>> casting to
>>> a  different function type, then calling through this new type, is
>>> undefined behaviour.  About the only useful thing you can do with
>>> your cast pointer is cast it back to the original type before calling
>>> it.
>>> So  g++ with -Wextra warns you that you have either made a mistake in
>>> your code, or are trying to do something that is potentially dangerous.
>>
>> He needs to store different function-pointers with a common type;
>> why not as a void-pointer ?
>
> As far as I know, the standards do not define the behaviour of casting
> between function pointers and void pointers (or any object pointers).
> The C standards are clear about the matter - it is not defined
> behaviour.  But I don't know the C++ standards well enough to say.
>

This is something about theory and practice. A function pointer is
allowed to be larger than a void*.

In practice both Linux/Posix and Windows will use void* for returning
function pointers into dynamic libraries. So on those systems it will
obviously work.

24.04.2024 10:36 Bonita Montero kirjutas:
> Am 23.04.2024 um 20:33 schrieb Paavo Helde:
>
>> The function pointers are cast to a single type so that they can be
>> stored in a common lookup array. ...
>
> Then you'd need additional information to distinguish the different
> types. If you have sth. like that you could take a variant<>.

Right, the varying part is the number of arguments, which is explicitly
declared and stored in the array as well (n_pars below). If you are
interested, the current code (no warnings any more here, thanks to
Markus!) looks like below. Not sure if changing to a variant or
void(*)() would make the code better, looks like then I would need to
add extra casts to all the lines in the table which currently do not
need any casts.

#include <math.h>

typedef double (*Func)(double);

struct formu_item {
const char *name;
Func f; /* pointer to function*/
int n_pars; /* number of parameters (0, 1, 2 or 3) */
int varying; /* Does the result of the function vary
even when the parameters stay the same?
varying=1 for e.g. random-number generators. */
};

typedef void (*VoidFunc)();
typedef double (*DoubleFunc_0_args)();
typedef double (*DoubleFunc_2_args)(double, double);

Func FuncCast2(DoubleFunc_2_args fp) {
return reinterpret_cast<Func>(reinterpret_cast<VoidFunc>(fp));
} Func FuncCast0(DoubleFunc_0_args fp) {
return reinterpret_cast<Func>(reinterpret_cast<VoidFunc>(fp));
} double pi() {
return 3.1415926535897932384626433832795029;
}

static const formu_item ftable_static[TABLESIZE]=
{ {"exp", exp,1,0},
{"ln", log,1,0},
{"sin", sin,1,0},
{"cos", cos,1,0},
{"tan", tan,1,0},
{"asin", asin,1,0},
{"acos", acos,1,0},
{"atan", atan,1,0},
{"atan2", FuncCast2(atan2),2,0},
{"abs", fabs,1,0},
{"sqrt", sqrt,1,0},
{"pi", FuncCast0(pi),0,0},
//...
}

On 24/04/2024 14:00, Bo Persson wrote:
> On 2024-04-24 at 13:14, David Brown wrote:
>> On 24/04/2024 11:27, Bonita Montero wrote:
>>> Am 23.04.2024 um 16:44 schrieb David Brown:
>>>
>>>> The compiler is warning here about casting incompatible function
>>>> types because usually such casts are a bad idea.  In particular,
>>>> casting to
>>>> a  different function type, then calling through this new type, is
>>>> undefined behaviour.  About the only useful thing you can do with
>>>> your cast pointer is cast it back to the original type before
>>>> calling it.
>>>> So  g++ with -Wextra warns you that you have either made a mistake in
>>>> your code, or are trying to do something that is potentially dangerous.
>>>
>>> He needs to store different function-pointers with a common type;
>>> why not as a void-pointer ?
>>
>> As far as I know, the standards do not define the behaviour of casting
>> between function pointers and void pointers (or any object pointers).
>> The C standards are clear about the matter - it is not defined
>> behaviour.  But I don't know the C++ standards well enough to say.
>>
>
> This is something about theory and practice. A function pointer is
> allowed to be larger than a void*.
>
> In practice both Linux/Posix and Windows will use void* for returning
> function pointers into dynamic libraries. So on those systems it will
> obviously work.
>

Sure. But I saw nothing in the OP's posts to indicate that he was using
POSIX or Windows. And it is silly to use "void *" pointers for generic
function pointers when "void (*)(void)" will work be design, rather than
luck, and is in no way more difficult or less efficient. (Note that
this is what the OP is already doing.)

Am 24.04.2024 um 13:23 schrieb David Brown:

> That may be true - but I am entirely confident that you don't know it is
> true.  You live in a little world where the only compiler is MSVC++ -
> you know nothing about the hundred other C++ compilers out there.  (I
> know more of them than you - and more importantly, I know my knowledge
> is limited.)

Any C++ compiler supports that since this is very common and you
coudln't port a lot of code to compilers who wouldn't understand
that. I've no problem using a union since this feature is required
for any compiler to be conformant with a lot of software.

Am 24.04.2024 um 13:14 schrieb David Brown:

> As far as I know, the standards do not define the behaviour of casting
> between function pointers and void pointers (or any object pointers).
> The C standards are clear about the matter - it is not defined
> behaviour.  But I don't know the C++ standards well enough to say.

There's for sure no compiler which doesn't support that.