On 10/03/17 23:34, Joseph Myers wrote:
> On Tue, 3 Oct 2017, Bernd Edlinger wrote:
>
>> invalid, also if both function types have a non-null TYPE_ARG_TYPES
>> I would say this deserves a warning. As an exception I have
>
> I'm not convinced by the TYPE_ARG_TYPES check, at least for C.
>
I will drop that, for C and C++, and try to get it working without
that kludge.
> In C, unprototyped function types are not compatible with variadic
> function types or functions with argument types changed by default
> argument promotions (that is, int () and int (char) and int (int, ...) are
> all incompatible). I'd think it appropriate to warn about such
> conversions, given that they are cases where calling the converted
> function has undefined behavior.
>
Right, interesting is that this does not produce a warning,
int test(int);
int foo()
{
int (*x)();
x = test;
return x(1);
}
while the following example produces a warning:
int test(int,...);
int foo()
{
int (*x)(int);
x = test;
return x(1);
}
gcc -Wall -W -S t1.c
t1.c: In function 'foo':
t1.c:6:5: warning: assignment to 'int (*)(int)' from incompatible
pointer type 'int (*)(int)' [-Wincompatible-pointer-types]
x = test;
^
I will send a patch that adds ", ..." to the parameter list
in the diagnostics...
But why is int(*)(int) compatible to (int)(*)() but not
to int(*)(int,...) ?
> There may well be cases of interfaces where void (*) (void) is used as a
> generic function pointer type (always converted to / from the actual type
> of the function in question), for which this warning would not be
> suitable.
>
Yes, those would get a warning, or have to add a cast to uintptr_t, if
it is not possible to fix the code otherwise. libffi does this...
Bernd.
