Re: warning in mingw [Was: [ANN] Lua 5.4.0 (rc1) now available]

[Roberto Ierusalimschy <roberto@...>]

> > Do other Windows enthusiasts have something to say about that? In
> > particular, to do that, wouldn't be better 'void(*)()' instead of
> > 'void(*)(void)'?

> No, void(*)() can't prevent the complaint of gcc.  Because "no
> parameter specification" is different from "no parameters" .

I know the two types are different, and that is why I proposed the other.
With '(void)' I am saying the function takes no arguments---which is
wrong---while with '()' I say nothing.


> Some references :
> 
> https://stackoverflow.com/questions/57014469/cast-between-incompatible-function-types-in-gcc
> https://stackoverflow.com/questions/31482624/is-there-such-a-thing-as-a-generic-function-pointer-in-c-that-can-be-assigned-ca
> https://stackoverflow.com/questions/53033813/can-you-cast-a-pointer-to-a-function-pointer-to-void
> https://stackoverflow.com/questions/51032/is-there-a-difference-between-foovoid-and-foo-in-c-or-c

What none of these references explains is why gcc complains when casting
to 'void(*)()' or to any other function pointer, but does not complain
when casting to 'void(*)(void)'.  Unlike (void*) for objects, the type
'void(*)(void)' has nothing special about it to prevent warnings.

>From the point of view of the standard, is all the same. As long as you
keep the reference as a pointer to function (any function!), and cast
it to the correct type when calling it, everything is guaranteed to work.
Why 'void(*)(void)' would be special? Do other compilers have this
same behavior, or is this a gcc kludge?

-- Roberto
_______________________________________________
lua-l mailing list -- lua-l@lists.lua.org
To unsubscribe send an email to lua-l-leave@lists.lua.org