Re: [PATCH] Add a warning for invalid function casts

[Jason Merrill]

On 10/09/2017 06:30 PM, Bernd Edlinger wrote:

+/* Heuristic check if two parameter types can be considered ABI-equivalent.  */
+
+static bool
+cxx_abi_equiv_type_p (tree t1, tree t2)


This name is too general for a function that is specifically for 
implementing a particular warning.



+  if (INTEGRAL_TYPE_P (t1)
+  && INTEGRAL_TYPE_P (t2)
+  && TYPE_PRECISION (t1) == TYPE_PRECISION (t2)
+  && (TYPE_UNSIGNED (t1) == TYPE_UNSIGNED (t2)
+ || TYPE_PRECISION (t1) >= TYPE_PRECISION (integer_type_node)))
+return true;


This section needs a comment explaining what you're allowing and why.

+  else if (TYPE_PTRMEMFUNC_P (type) && TYPE_PTRMEMFUNC_P (intype))
+{
+  if ((complain & tf_warning)
+ && !same_type_p (type, intype))


Why not use cxx_safe_function_type_cast_p here, too? 
TYPE_PTRMEMFUNC_FN_TYPE will be helpful.


Jason

[PING**2] [PATCH] Add a warning for invalid function casts

[Bernd Edlinger]

Ping...

On 11/08/17 17:55, Bernd Edlinger wrote:
> Ping...
> 
> for the C++ part of this patch:
> 
> https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00559.html
> 
> 
> Thanks
> Bernd.
> 
>> On 10/10/17 00:30, Bernd Edlinger wrote:
>>> On 10/09/17 20:34, Martin Sebor wrote:
 On 10/09/2017 11:50 AM, Bernd Edlinger wrote:
> On 10/09/17 18:44, Martin Sebor wrote:
>> On 10/07/2017 10:48 AM, Bernd Edlinger wrote:
>>> Hi!
>>>
>>> I think I have now something useful, it has a few more heuristics
>>> added, to reduce the number of false-positives so that it
>>> is able to find real bugs, for instance in openssl it triggers
>>> at a function cast which has already a TODO on it.
>>>
>>> The heuristics are:
>>> - handle void (*)(void) as a wild-card function type.
>>> - ignore volatile, const qualifiers on parameters/return.
>>> - handle any pointers as equivalent.
>>> - handle integral types, enums, and booleans of same precision
>>>     and signedness as equivalent.
>>> - stop parameter validation at the first "...".
>>
>> These sound quite reasonable to me.  I have a reservation about
>> just one of them, and some comments about other aspects of the
>> warning.  Sorry if this seems like a lot.  I'm hoping you'll
>> find the feedback constructive.
>>
>> I don't think using void(*)(void) to suppress the warning is
>> a robust solution because it's not safe to call a function that
>> takes arguments through such a pointer (especially not if one
>> or more of the arguments is a pointer).  Depending on the ABI,
>> calling a function that expects arguments with none could also
>> mess up the stack as the callee may pop arguments that were
>> never passed to it.
>>
>
> This is of course only a heuristic, and if there is no warning
> that does not mean any guarantee that there can't be a problem
> at runtime.  The heuristic is only meant to separate the
> bad from the very bad type-cast.  In my personal opinion there
> is not a single good type cast.

 I agree.  Since the warning uses one kind of a cast as an escape
 mechanism from the checking it should be one whose result can
 the most likely be used to call the function without undefined
 behavior.

 Since it's possible to call any function through a pointer to
 a function with no arguments (simply by providing arguments of
 matching types) it's a reasonable candidate.

 On the other hand, since it is not safe to call an arbitrary
 function through void (*)(void), it's not as good a candidate.

 Another reason why I think a protoype-less function is a good
 choice is because the alias and ifunc attributes already use it
 as an escape mechanism from their type incompatibility warning.

>>>
>>> I know of pre-existing code-bases where a type-cast to type:
>>> void (*) (void);
>>>
>>> .. is already used as a generic function pointer: libffi and
>>> libgo, I would not want to break these.
>>>
>>> Actually when I have a type:
>>> X (*) (...);
>>>
>>> I would like to make sure that the warning checks that
>>> only functions returning X are assigned.
>>>
>>> and for X (*) (Y, );
>>>
>>> I would like to check that anything returning X with
>>> first argument of type Y is assigned.
>>>
>>> There are code bases where such a scheme is used.
>>> For instance one that I myself maintain: the OPC/UA AnsiC Stack,
>>> where I have this type definition:
>>>
>>> typedef OpcUa_StatusCode (OpcUa_PfnInvokeService)(OpcUa_Endpoint
>>> hEndpoint, ...);
>>>
>>> And this plays well together with this warning, because only
>>> functions are assigned that match up to the ...);
>>> Afterwards this pointer is cast back to the original signature,
>>> so everything is perfectly fine.
>>>
>>> Regarding the cast from pointer to member to function, I see also a
>>> warning without -Wpedantic:
>>> Warnung: converting from »void (S::*)(int*)« to »void (*)(int*)«
>>> [-Wpmf-conversions]
>>>  F *pf = (F*)::foo;
>>>  ^~~
>>>
>>> And this one is even default-enabled, so I think that should be
>>> more than sufficient.
>>>
>>> I also changed the heuristic, so that your example with the enum should
>>> now work.  I did not add it to the test case, because it would
>>> break with -fshort-enums :(
>>>
>>> Attached I have an updated patch that extends this warning to the
>>> pointer-to-member function cast, and relaxes the heuristic on the
>>> benign integral type differences a bit further.
>>>
>>>
>>> Is it OK for trunk after bootstrap and reg-testing?
>>>
>>>
>>> Thanks
>>> Bernd.
>>>

[PING] [PATCH] Add a warning for invalid function casts

[Bernd Edlinger]

Ping...

for the C++ part of this patch:

https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00559.html


Thanks
Bernd.

> On 10/10/17 00:30, Bernd Edlinger wrote:
>> On 10/09/17 20:34, Martin Sebor wrote:
>>> On 10/09/2017 11:50 AM, Bernd Edlinger wrote:
 On 10/09/17 18:44, Martin Sebor wrote:
> On 10/07/2017 10:48 AM, Bernd Edlinger wrote:
>> Hi!
>>
>> I think I have now something useful, it has a few more heuristics
>> added, to reduce the number of false-positives so that it
>> is able to find real bugs, for instance in openssl it triggers
>> at a function cast which has already a TODO on it.
>>
>> The heuristics are:
>> - handle void (*)(void) as a wild-card function type.
>> - ignore volatile, const qualifiers on parameters/return.
>> - handle any pointers as equivalent.
>> - handle integral types, enums, and booleans of same precision
>>     and signedness as equivalent.
>> - stop parameter validation at the first "...".
>
> These sound quite reasonable to me.  I have a reservation about
> just one of them, and some comments about other aspects of the
> warning.  Sorry if this seems like a lot.  I'm hoping you'll
> find the feedback constructive.
>
> I don't think using void(*)(void) to suppress the warning is
> a robust solution because it's not safe to call a function that
> takes arguments through such a pointer (especially not if one
> or more of the arguments is a pointer).  Depending on the ABI,
> calling a function that expects arguments with none could also
> mess up the stack as the callee may pop arguments that were
> never passed to it.
>

 This is of course only a heuristic, and if there is no warning
 that does not mean any guarantee that there can't be a problem
 at runtime.  The heuristic is only meant to separate the
 bad from the very bad type-cast.  In my personal opinion there
 is not a single good type cast.
>>>
>>> I agree.  Since the warning uses one kind of a cast as an escape
>>> mechanism from the checking it should be one whose result can
>>> the most likely be used to call the function without undefined
>>> behavior.
>>>
>>> Since it's possible to call any function through a pointer to
>>> a function with no arguments (simply by providing arguments of
>>> matching types) it's a reasonable candidate.
>>>
>>> On the other hand, since it is not safe to call an arbitrary
>>> function through void (*)(void), it's not as good a candidate.
>>>
>>> Another reason why I think a protoype-less function is a good
>>> choice is because the alias and ifunc attributes already use it
>>> as an escape mechanism from their type incompatibility warning.
>>>
>>
>> I know of pre-existing code-bases where a type-cast to type:
>> void (*) (void);
>>
>> .. is already used as a generic function pointer: libffi and
>> libgo, I would not want to break these.
>>
>> Actually when I have a type:
>> X (*) (...);
>>
>> I would like to make sure that the warning checks that
>> only functions returning X are assigned.
>>
>> and for X (*) (Y, );
>>
>> I would like to check that anything returning X with
>> first argument of type Y is assigned.
>>
>> There are code bases where such a scheme is used.
>> For instance one that I myself maintain: the OPC/UA AnsiC Stack,
>> where I have this type definition:
>>
>> typedef OpcUa_StatusCode (OpcUa_PfnInvokeService)(OpcUa_Endpoint
>> hEndpoint, ...);
>>
>> And this plays well together with this warning, because only
>> functions are assigned that match up to the ...);
>> Afterwards this pointer is cast back to the original signature,
>> so everything is perfectly fine.
>>
>> Regarding the cast from pointer to member to function, I see also a
>> warning without -Wpedantic:
>> Warnung: converting from »void (S::*)(int*)« to »void (*)(int*)«
>> [-Wpmf-conversions]
>>  F *pf = (F*)::foo;
>>  ^~~
>>
>> And this one is even default-enabled, so I think that should be
>> more than sufficient.
>>
>> I also changed the heuristic, so that your example with the enum should
>> now work.  I did not add it to the test case, because it would
>> break with -fshort-enums :(
>>
>> Attached I have an updated patch that extends this warning to the
>> pointer-to-member function cast, and relaxes the heuristic on the
>> benign integral type differences a bit further.
>>
>>
>> Is it OK for trunk after bootstrap and reg-testing?
>>
>>
>> Thanks
>> Bernd.
>>

Re: [PATCH] Add a warning for invalid function casts

[Joseph Myers]

On Mon, 9 Oct 2017, Bernd Edlinger wrote:

> +type @code{void (*) (void);} is special and matches everything, which can

The type name should not include ";".

The non-C++ parts of the patch are OK with that change.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] Add a warning for invalid function casts

[Bernd Edlinger]

Ping...

for the latest version of my patch which can be found here:

https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00559.html


Thanks
Bernd.

On 10/10/17 00:30, Bernd Edlinger wrote:
> On 10/09/17 20:34, Martin Sebor wrote:
>> On 10/09/2017 11:50 AM, Bernd Edlinger wrote:
>>> On 10/09/17 18:44, Martin Sebor wrote:
 On 10/07/2017 10:48 AM, Bernd Edlinger wrote:
> Hi!
>
> I think I have now something useful, it has a few more heuristics
> added, to reduce the number of false-positives so that it
> is able to find real bugs, for instance in openssl it triggers
> at a function cast which has already a TODO on it.
>
> The heuristics are:
> - handle void (*)(void) as a wild-card function type.
> - ignore volatile, const qualifiers on parameters/return.
> - handle any pointers as equivalent.
> - handle integral types, enums, and booleans of same precision
>     and signedness as equivalent.
> - stop parameter validation at the first "...".

 These sound quite reasonable to me.  I have a reservation about
 just one of them, and some comments about other aspects of the
 warning.  Sorry if this seems like a lot.  I'm hoping you'll
 find the feedback constructive.

 I don't think using void(*)(void) to suppress the warning is
 a robust solution because it's not safe to call a function that
 takes arguments through such a pointer (especially not if one
 or more of the arguments is a pointer).  Depending on the ABI,
 calling a function that expects arguments with none could also
 mess up the stack as the callee may pop arguments that were
 never passed to it.

>>>
>>> This is of course only a heuristic, and if there is no warning
>>> that does not mean any guarantee that there can't be a problem
>>> at runtime.  The heuristic is only meant to separate the
>>> bad from the very bad type-cast.  In my personal opinion there
>>> is not a single good type cast.
>>
>> I agree.  Since the warning uses one kind of a cast as an escape
>> mechanism from the checking it should be one whose result can
>> the most likely be used to call the function without undefined
>> behavior.
>>
>> Since it's possible to call any function through a pointer to
>> a function with no arguments (simply by providing arguments of
>> matching types) it's a reasonable candidate.
>>
>> On the other hand, since it is not safe to call an arbitrary
>> function through void (*)(void), it's not as good a candidate.
>>
>> Another reason why I think a protoype-less function is a good
>> choice is because the alias and ifunc attributes already use it
>> as an escape mechanism from their type incompatibility warning.
>>
> 
> I know of pre-existing code-bases where a type-cast to type:
> void (*) (void);
> 
> .. is already used as a generic function pointer: libffi and
> libgo, I would not want to break these.
> 
> Actually when I have a type:
> X (*) (...);
> 
> I would like to make sure that the warning checks that
> only functions returning X are assigned.
> 
> and for X (*) (Y, );
> 
> I would like to check that anything returning X with
> first argument of type Y is assigned.
> 
> There are code bases where such a scheme is used.
> For instance one that I myself maintain: the OPC/UA AnsiC Stack,
> where I have this type definition:
> 
> typedef OpcUa_StatusCode (OpcUa_PfnInvokeService)(OpcUa_Endpoint
> hEndpoint, ...);
> 
> And this plays well together with this warning, because only
> functions are assigned that match up to the ...);
> Afterwards this pointer is cast back to the original signature,
> so everything is perfectly fine.
> 
> Regarding the cast from pointer to member to function, I see also a
> warning without -Wpedantic:
> Warnung: converting from »void (S::*)(int*)« to »void (*)(int*)«
> [-Wpmf-conversions]
>  F *pf = (F*)::foo;
>  ^~~
> 
> And this one is even default-enabled, so I think that should be
> more than sufficient.
> 
> I also changed the heuristic, so that your example with the enum should
> now work.  I did not add it to the test case, because it would
> break with -fshort-enums :(
> 
> Attached I have an updated patch that extends this warning to the
> pointer-to-member function cast, and relaxes the heuristic on the
> benign integral type differences a bit further.
> 
> 
> Is it OK for trunk after bootstrap and reg-testing?
> 
> 
> Thanks
> Bernd.
> 

Re: [PATCH] Add a warning for invalid function casts

[Joseph Myers]

On Thu, 12 Oct 2017, Martin Sebor wrote:

> Yes.  In light of this discussion I am thinking it might be
> worthwhile to bring up the issue of generic function pointers
> with WG14 for C2X.

I'm fine with the idea of having a standard solution that (unlike void (*) 
(void)) cannot be called at all without converting to another type.  I 
just maintain that void (*) (void) is the de facto idiom for this and so 
the warning should reflect this even in the future presence of such a 
standard solution (much as we e.g. handle trailing [1] arrays in structs 
as possibly being used as flexible array members in code using that as a 
C89/C++-compatible idiom rather than relying on C99 flexible array 
members).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] Add a warning for invalid function casts

[Martin Sebor]

On 10/12/2017 05:52 AM, Pedro Alves wrote:

On 10/11/2017 03:57 AM, Martin Sebor wrote:



[X] This can be function that takes an argument of an incomplete
type, such as:

  struct Incomplete;
  typedef void Uncallable (struct Incomplete);

Any function can safely be converted to Uncallable* without
the risk of being called with the wrong arguments.  The only
way to use an Uncallable* is to explicitly convert it to
a pointer to a function that can be called.


OOC, did you consider trying to get something like that added
to C proper, to some standard header?  I don't imagine that it'd
be much objectionable, and having a standard type may help
tooling give better diagnostics and suggestions.


Yes.  In light of this discussion I am thinking it might be
worthwhile to bring up the issue of generic function pointers
with WG14 for C2X.

Martin

Re: [PATCH] Add a warning for invalid function casts

[Pedro Alves]

On 10/11/2017 03:57 AM, Martin Sebor wrote:
> 
> 
> [X] This can be function that takes an argument of an incomplete
> type, such as:
> 
>   struct Incomplete;
>   typedef void Uncallable (struct Incomplete);
> 
> Any function can safely be converted to Uncallable* without
> the risk of being called with the wrong arguments.  The only
> way to use an Uncallable* is to explicitly convert it to
> a pointer to a function that can be called.

OOC, did you consider trying to get something like that added
to C proper, to some standard header?  I don't imagine that it'd
be much objectionable, and having a standard type may help
tooling give better diagnostics and suggestions.

Thanks,
Pedro Alves

Re: [PATCH] Add a warning for invalid function casts

[Pedro Alves]

On 10/11/2017 03:57 AM, Martin Sebor wrote:
> 
> 
> Incidentally, void(*)(void) in C++ is a poor choice for this
> use case also because of the language's default function
> arguments.  It's an easy mistake for a C++ programmer to make
> to assume that given, say:
> 
>   void foo (const char *s = "...");
> 
> or for any other function that provides default values for all
> its arguments, the function may be callable via void(*)(void):
> 
>   typedef void F (void);
> 
>   void (pf)(void) = (F*)foo;

I'd think it'd be much more common to write instead:

  typedef void F (void);

  F *pf = (F*)foo;

I.e., use the typedef on both sides of the assignment.

> 
> by having the (default) function argument value(s) magically
> substituted at the call site of:
> 
>pf ();
> 
> Bu since that's not the case it would be helpful for the new
> warning to detect this mistake.  By encouraging the use of
> 
>   typedef void F (...);
> 
> as the type of a pointer there is little chance of making such
> a mistake.

(and then) I don't think I understand this rationale.
If users follow the advice, they'll end up with:

  void foo (const char *s = "...");
  typedef void F (...);
  F *pf = (F *)foo;
  pf ();

which still compiles silently and calls the foo
function incorrectly.

Thanks,
Pedro Alves

Re: [PATCH] Add a warning for invalid function casts

[Pedro Alves]

On 10/11/2017 06:58 PM, Martin Sebor wrote:
> On 10/11/2017 11:26 AM, Joseph Myers wrote:
>> On Tue, 10 Oct 2017, Martin Sebor wrote:
>>
>>> The ideal solution for 1) would be a function pointer that can
>>> never be used to call a function (i.e., the void* equivalent
>>> for functions).[X]
>>
>> I don't think that's relevant.  The normal idiom for this in modern C
>> code, if not just using void *, is void (*) (void), and since the warning
>> is supposed to be avoiding excessive false positives and detecting the
>> cases that are likely to be used for ABI-incompatible calls, the warning
>> should allow void (*) (void) there.
> 
> I think we'll just have to agree to disagree.  I'm not convinced
> that using void(*)(void) for this is idiomatic or pervasive enough
> to drive design decisions.  Bernd mentioned just libgo and libffi
> as the code bases that do, and both you and I have noted that any
> pointer type works equally well for this purpose.  The problem
> with almost any type, including void(*) (void), is that they can
> be misused to call the incompatible function.  Since the sole
> purpose of this new warning is to help find those misuses,
> excluding void(*)(void) from the checking is directly at odds
> with its goal.

Switching type-erased function pointers from "void(*)(void)"
to "void(*)()" (in C) substantially increases the risk of code
calling the type-erased pointer without casting it back by accident:

 extern void foo (int, int);
 typedef void (type_erased_func) (void);
 type_erased_func *func = (type_erased_func *) foo;

 int main ()
 {
   func (1, 2); // error: too many arguments
 }

vs:

 extern void foo (int, int);
 typedef void (type_erased_func) (); // note: void dropped
 type_erased_func *func = (type_erased_func *) foo;

 int main ()
 {
   func (1, 2); // whoops, now silently compiles
 }

I think it'd be good if this were weighed in as well.  If 'void ()'
is picked as the special type, then maybe the above could
be at least addressed in the documentation, and/or
diagnostics/notes.

Thanks,
Pedro Alves

Re: [PATCH] Add a warning for invalid function casts

[Martin Sebor]

On 10/11/2017 11:26 AM, Joseph Myers wrote:

On Tue, 10 Oct 2017, Martin Sebor wrote:


The ideal solution for 1) would be a function pointer that can
never be used to call a function (i.e., the void* equivalent
for functions).[X]


I don't think that's relevant.  The normal idiom for this in modern C
code, if not just using void *, is void (*) (void), and since the warning
is supposed to be avoiding excessive false positives and detecting the
cases that are likely to be used for ABI-incompatible calls, the warning
should allow void (*) (void) there.


I think we'll just have to agree to disagree.  I'm not convinced
that using void(*)(void) for this is idiomatic or pervasive enough
to drive design decisions.  Bernd mentioned just libgo and libffi
as the code bases that do, and both you and I have noted that any
pointer type works equally well for this purpose.  The problem
with almost any type, including void(*) (void), is that they can
be misused to call the incompatible function.  Since the sole
purpose of this new warning is to help find those misuses,
excluding void(*)(void) from the checking is directly at odds
with its goal.

I would prefer not to design an unnecessary back door into
the implementation and compromise the effectiveness of the warning
for what's clearly an inferior choice made without fully considering
the risk of misusing the result.  Instead I hope the warning will
drive improvements to code to make its intent explicit.  In my view
that's a good thing even if the code works correctly today.

I don't know how much code there is out that uses void (*)(void)
as a generic function pointer that's never intended to be called.
but I wouldn't expect there to be so much of it to make my
suggestion unfeasible.  I could of course be wrong.  If I am,
we'd find out pretty quickly.

But I've exhausted my arguments and so I think it's time for
me to bow out of the discussion.

Martin

Re: [PATCH] Add a warning for invalid function casts

[Joseph Myers]

On Tue, 10 Oct 2017, Martin Sebor wrote:

> The ideal solution for 1) would be a function pointer that can
> never be used to call a function (i.e., the void* equivalent
> for functions).[X]

I don't think that's relevant.  The normal idiom for this in modern C 
code, if not just using void *, is void (*) (void), and since the warning 
is supposed to be avoiding excessive false positives and detecting the 
cases that are likely to be used for ABI-incompatible calls, the warning 
should allow void (*) (void) there.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] Add a warning for invalid function casts

[Martin Sebor]

On 10/10/2017 03:48 PM, Joseph Myers wrote:

On Tue, 10 Oct 2017, Martin Sebor wrote:


Calling a function that takes arguments via a void (*)(void)
is undefined not just on paper but also in practice, so the
resulting pointer from such a cast is unusable except to convert
to a compatible pointer.


That's the point of a generic pointer - it either gets cast to the actual
type (or something ABI-compatible with the actual type) for calls, or
called from non-C code which has the same effect.


Sure.  But (as you note below) any function pointer can be used
as a generic function pointer.  There's nothing unique or special
about void (*)(void) to make it particularly suitable for this
purpose.

But we're conflating two use cases: 1) converting to a generic
function pointer that's never used to call a function, and 2)
converting to a function pointer that's used to call a function
not strictly compatible with it but where the ABI obviates
the incompatibility.

The ideal solution for 1) would be a function pointer that can
never be used to call a function (i.e., the void* equivalent
for functions).[X]

I argue the ideal solution for 2) is void (*)() (or something
like it).  It's superior to void(*)(void) because it makes its
intent in a cast clear: ignore the types of the target function's
formal arguments.  Contrast that with void(*)(void) which could
mean one of two things: a) follow the type system rules, or b)
treat it as special and ignore the type system.  Accepting (b)
when (a) so clearly expresses the intent of this use case seems
like a clearly inferior choice to me.


PS It would be useful if modern C provided a clean mechanism to
support generic function pointers rather that forcing users leery
of relying on obsolescent features to invent workarounds.  One


You can use any function pointer type whatever as your generic pointer
(casting back to the original type for calls).  That you can cast from one
function pointer type to another and back to the original type is
guaranteed by ISO C.  That the result of the conversion is meaningful for
calls from non-C languages is part of the customary practices of C
implementations.  That the type used is void (*) (void) is a common
convention used in C code dealing with generic function pointers (another
convention, of course, is just using void * as in POSIX and relying on
conversions between function pointers and void *).


Right.  The problem Bernd and I are trying to solve is how to
distinguish the last one from the other two use cases on this
list:

1) a conversion of an arbitrary function to a generic pointer
   that's only used for storage but never to call the function
   directly, without converting it to the original function's
   type (see also [X] below),
2) a conversion of an arbitrary function to some strictly
   incompatible type that is nonetheless safe to use (by the
   ABI rules) to call the original function, and
3) all other conversions that are likely mistakes/bugs and
   that should be diagnosed.

My claim, again, is that using void(*)() for both (1) and (2)
above (or a moral equivalent of it, such as void(*)(...)) is
a superior solution than any other that we have seen, including
void(*)(void), because it clearly expresses the intent (no type
checking) and doesn't exclude any type from the set to check for
compatibility.

Incidentally, void(*)(void) in C++ is a poor choice for this
use case also because of the language's default function
arguments.  It's an easy mistake for a C++ programmer to make
to assume that given, say:

  void foo (const char *s = "...");

or for any other function that provides default values for all
its arguments, the function may be callable via void(*)(void):

  typedef void F (void);

  void (pf)(void) = (F*)foo;

by having the (default) function argument value(s) magically
substituted at the call site of:

   pf ();

Bu since that's not the case it would be helpful for the new
warning to detect this mistake.  By encouraging the use of

  typedef void F (...);

as the type of a pointer there is little chance of making such
a mistake.

Martin

[X] This can be function that takes an argument of an incomplete
type, such as:

  struct Incomplete;
  typedef void Uncallable (struct Incomplete);

Any function can safely be converted to Uncallable* without
the risk of being called with the wrong arguments.  The only
way to use an Uncallable* is to explicitly convert it to
a pointer to a function that can be called.

Re: [PATCH] Add a warning for invalid function casts

[Joseph Myers]

On Tue, 10 Oct 2017, Martin Sebor wrote:

> Calling a function that takes arguments via a void (*)(void)
> is undefined not just on paper but also in practice, so the
> resulting pointer from such a cast is unusable except to convert
> to a compatible pointer.

That's the point of a generic pointer - it either gets cast to the actual 
type (or something ABI-compatible with the actual type) for calls, or 
called from non-C code which has the same effect.

> PS It would be useful if modern C provided a clean mechanism to
> support generic function pointers rather that forcing users leery
> of relying on obsolescent features to invent workarounds.  One

You can use any function pointer type whatever as your generic pointer 
(casting back to the original type for calls).  That you can cast from one 
function pointer type to another and back to the original type is 
guaranteed by ISO C.  That the result of the conversion is meaningful for 
calls from non-C languages is part of the customary practices of C 
implementations.  That the type used is void (*) (void) is a common 
convention used in C code dealing with generic function pointers (another 
convention, of course, is just using void * as in POSIX and relying on 
conversions between function pointers and void *).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] Add a warning for invalid function casts

[Martin Sebor]

On 10/10/2017 10:30 AM, Joseph Myers wrote:

On Tue, 10 Oct 2017, Martin Sebor wrote:


I know of pre-existing code-bases where a type-cast to type:
void (*) (void);

.. is already used as a generic function pointer: libffi and
libgo, I would not want to break these.


Why not fix them instead?  They're a part of GCC so it should
be straightforward.  It doesn't seem like a good tradeoff to


Sometimes an interface needs to store an arbitrary function type for which
an ABI-compliant call ends up being constructed at runtime from assembly
language (or from non-C, in general).  That's the sort of thing libffi
does - so it inherently needs to be able to take pointers to arbitrary
function types, which thus need to be converted to a generic function
type, and the de facto generic function pointer type in C is void (*)
(void).  (C11 6.11.6 says "The use of function declarators with empty
parentheses (not prototype-format parameter type declarators) is an
obsolescent feature.", so void (*) () is best avoided.)  Likewise
interfaces such as dlsym (which happens to return void * along with a
special case in POSIX requiring conversions between void * and function
pointers to work, but void (*) (void) is the natural type for such
interfaces to use).


I agree that unprototyped functions are best avoided in cases
where type checking is needed (i.e., in most use cases).  I also
agree that "generic function pointers") are not uncommon and are
worth accommodating.

But I don't think that adopting an inferior mechanism for it when
a better alternative exists is helpful.

Calling a function that takes arguments via a void (*)(void)
is undefined not just on paper but also in practice, so the
resulting pointer from such a cast is unusable except to convert
to a compatible pointer.

On the other hand, it is well-defined or safe to use a void (*)()
to call essentially any function, so it is a superior choice for
this use case.  Even if the pointer is only used for storage and
never to call a function, the syntax is elegant and the intent
clear.

Martin

PS It would be useful if modern C provided a clean mechanism to
support generic function pointers rather that forcing users leery
of relying on obsolescent features to invent workarounds.  One
alternative is to unobsolesce unprototyped functions for this
use case (i.e., for pointers to functions).  Another might be to
invent some other syntax (e.g., void (*)(...) since it's accepted
in C++).  But using void(*)(void) feels like a hack to me.

Re: [PATCH] Add a warning for invalid function casts

[Joseph Myers]

On Tue, 10 Oct 2017, Martin Sebor wrote:

> > I know of pre-existing code-bases where a type-cast to type:
> > void (*) (void);
> > 
> > .. is already used as a generic function pointer: libffi and
> > libgo, I would not want to break these.
> 
> Why not fix them instead?  They're a part of GCC so it should
> be straightforward.  It doesn't seem like a good tradeoff to

Sometimes an interface needs to store an arbitrary function type for which 
an ABI-compliant call ends up being constructed at runtime from assembly 
language (or from non-C, in general).  That's the sort of thing libffi 
does - so it inherently needs to be able to take pointers to arbitrary 
function types, which thus need to be converted to a generic function 
type, and the de facto generic function pointer type in C is void (*) 
(void).  (C11 6.11.6 says "The use of function declarators with empty 
parentheses (not prototype-format parameter type declarators) is an 
obsolescent feature.", so void (*) () is best avoided.)  Likewise 
interfaces such as dlsym (which happens to return void * along with a 
special case in POSIX requiring conversions between void * and function 
pointers to work, but void (*) (void) is the natural type for such 
interfaces to use).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] Add a warning for invalid function casts

[Martin Sebor]

On 10/09/2017 04:30 PM, Bernd Edlinger wrote:

On 10/09/17 20:34, Martin Sebor wrote:

On 10/09/2017 11:50 AM, Bernd Edlinger wrote:

On 10/09/17 18:44, Martin Sebor wrote:

On 10/07/2017 10:48 AM, Bernd Edlinger wrote:

Hi!

I think I have now something useful, it has a few more heuristics
added, to reduce the number of false-positives so that it
is able to find real bugs, for instance in openssl it triggers
at a function cast which has already a TODO on it.

The heuristics are:
- handle void (*)(void) as a wild-card function type.
- ignore volatile, const qualifiers on parameters/return.
- handle any pointers as equivalent.
- handle integral types, enums, and booleans of same precision
   and signedness as equivalent.
- stop parameter validation at the first "...".


These sound quite reasonable to me.  I have a reservation about
just one of them, and some comments about other aspects of the
warning.  Sorry if this seems like a lot.  I'm hoping you'll
find the feedback constructive.

I don't think using void(*)(void) to suppress the warning is
a robust solution because it's not safe to call a function that
takes arguments through such a pointer (especially not if one
or more of the arguments is a pointer).  Depending on the ABI,
calling a function that expects arguments with none could also
mess up the stack as the callee may pop arguments that were
never passed to it.



This is of course only a heuristic, and if there is no warning
that does not mean any guarantee that there can't be a problem
at runtime.  The heuristic is only meant to separate the
bad from the very bad type-cast.  In my personal opinion there
is not a single good type cast.


I agree.  Since the warning uses one kind of a cast as an escape
mechanism from the checking it should be one whose result can
the most likely be used to call the function without undefined
behavior.

Since it's possible to call any function through a pointer to
a function with no arguments (simply by providing arguments of
matching types) it's a reasonable candidate.

On the other hand, since it is not safe to call an arbitrary
function through void (*)(void), it's not as good a candidate.

Another reason why I think a protoype-less function is a good
choice is because the alias and ifunc attributes already use it
as an escape mechanism from their type incompatibility warning.



I know of pre-existing code-bases where a type-cast to type:
void (*) (void);

.. is already used as a generic function pointer: libffi and
libgo, I would not want to break these.


Why not fix them instead?  They're a part of GCC so it should
be straightforward.  It doesn't seem like a good tradeoff to
compromise the efficacy of the warning to accommodate a couple
of questionable use cases.



Actually when I have a type:
X (*) (...);

I would like to make sure that the warning checks that
only functions returning X are assigned.

and for X (*) (Y, );

I would like to check that anything returning X with
first argument of type Y is assigned.

There are code bases where such a scheme is used.
For instance one that I myself maintain: the OPC/UA AnsiC Stack,
where I have this type definition:

typedef OpcUa_StatusCode (OpcUa_PfnInvokeService)(OpcUa_Endpoint
hEndpoint, ...);


If GCC guarantees that a variadic function can safely be called
with a pointer to another variadic function it seems reasonable
to avoid warning on such conversions.  But I'm not sure I see
what bearing this use case has on the one with functions without
a prototype.  In C++, void (*)(...) is the equivalent of
void (*)() in C, and so any function can be cast to it with no
warning because it can be safely called by providing the right
arguments.  Ignoring the return type should likewise be safe.
This feels like a clean design, while using void (*)(void)
like an unnecessary exception.


And this plays well together with this warning, because only
functions are assigned that match up to the ...);
Afterwards this pointer is cast back to the original signature,
so everything is perfectly fine.


I tend to agree.


Regarding the cast from pointer to member to function, I see also a
warning without -Wpedantic:
Warnung: converting from »void (S::*)(int*)« to »void (*)(int*)«
[-Wpmf-conversions]
F *pf = (F*)::foo;
^~~

And this one is even default-enabled, so I think that should be
more than sufficient.


I agree.  It looks like this triggers -Wpedantic when -Wpedantic
is set and -Wpmf-conversions when it isn't.  (It seems odd but
adding it under yet another warning option wouldn't help.)

Warning on the other test case would, however, be useful:

  struct S { void foo (int*); };

  typedef void (S::*MF)(int);

  MF pmf = (MF)::foo;

Martin

Re: [PATCH] Add a warning for invalid function casts

[Bernd Edlinger]

On 10/09/17 20:34, Martin Sebor wrote:
> On 10/09/2017 11:50 AM, Bernd Edlinger wrote:
>> On 10/09/17 18:44, Martin Sebor wrote:
>>> On 10/07/2017 10:48 AM, Bernd Edlinger wrote:
 Hi!

 I think I have now something useful, it has a few more heuristics
 added, to reduce the number of false-positives so that it
 is able to find real bugs, for instance in openssl it triggers
 at a function cast which has already a TODO on it.

 The heuristics are:
 - handle void (*)(void) as a wild-card function type.
 - ignore volatile, const qualifiers on parameters/return.
 - handle any pointers as equivalent.
 - handle integral types, enums, and booleans of same precision
    and signedness as equivalent.
 - stop parameter validation at the first "...".
>>>
>>> These sound quite reasonable to me.  I have a reservation about
>>> just one of them, and some comments about other aspects of the
>>> warning.  Sorry if this seems like a lot.  I'm hoping you'll
>>> find the feedback constructive.
>>>
>>> I don't think using void(*)(void) to suppress the warning is
>>> a robust solution because it's not safe to call a function that
>>> takes arguments through such a pointer (especially not if one
>>> or more of the arguments is a pointer).  Depending on the ABI,
>>> calling a function that expects arguments with none could also
>>> mess up the stack as the callee may pop arguments that were
>>> never passed to it.
>>>
>>
>> This is of course only a heuristic, and if there is no warning
>> that does not mean any guarantee that there can't be a problem
>> at runtime.  The heuristic is only meant to separate the
>> bad from the very bad type-cast.  In my personal opinion there
>> is not a single good type cast.
> 
> I agree.  Since the warning uses one kind of a cast as an escape
> mechanism from the checking it should be one whose result can
> the most likely be used to call the function without undefined
> behavior.
> 
> Since it's possible to call any function through a pointer to
> a function with no arguments (simply by providing arguments of
> matching types) it's a reasonable candidate.
> 
> On the other hand, since it is not safe to call an arbitrary
> function through void (*)(void), it's not as good a candidate.
> 
> Another reason why I think a protoype-less function is a good
> choice is because the alias and ifunc attributes already use it
> as an escape mechanism from their type incompatibility warning.
> 

I know of pre-existing code-bases where a type-cast to type:
void (*) (void);

.. is already used as a generic function pointer: libffi and
libgo, I would not want to break these.

Actually when I have a type:
X (*) (...);

I would like to make sure that the warning checks that
only functions returning X are assigned.

and for X (*) (Y, );

I would like to check that anything returning X with
first argument of type Y is assigned.

There are code bases where such a scheme is used.
For instance one that I myself maintain: the OPC/UA AnsiC Stack,
where I have this type definition:

typedef OpcUa_StatusCode (OpcUa_PfnInvokeService)(OpcUa_Endpoint 
hEndpoint, ...);

And this plays well together with this warning, because only
functions are assigned that match up to the ...);
Afterwards this pointer is cast back to the original signature,
so everything is perfectly fine.

Regarding the cast from pointer to member to function, I see also a
warning without -Wpedantic:
Warnung: converting from »void (S::*)(int*)« to »void (*)(int*)« 
[-Wpmf-conversions]
F *pf = (F*)::foo;
^~~

And this one is even default-enabled, so I think that should be
more than sufficient.

I also changed the heuristic, so that your example with the enum should
now work.  I did not add it to the test case, because it would
break with -fshort-enums :(

Attached I have an updated patch that extends this warning to the
pointer-to-member function cast, and relaxes the heuristic on the
benign integral type differences a bit further.


Is it OK for trunk after bootstrap and reg-testing?


Thanks
Bernd.
gcc:
2017-10-06  Bernd Edlinger  

* doc/invoke.texi: Document -Wcast-function-type.
* recog.h (stored_funcptr): Change signature.
* tree-dump.c (dump_node): Avoid warning.
* typed-splay-tree.h (typed_splay_tree): Avoid warning.

libcpp:
2017-10-06  Bernd Edlinger  

* internal.h (maybe_print_line): Change signature.

c-family:
2017-10-06  Bernd Edlinger  

* c.opt (Wcast-function-type): New warning option.
* c-lex.c (get_fileinfo): Avoid warning.
* c-ppoutput.c (scan_translation_unit_directives_only): Remove cast.

c:
2017-10-06  Bernd Edlinger  

* c-typeck.c (c_abi_equiv_type_p, c_safe_function_type_cast_p): New.
(build_c_cast): Implement -Wcast_function_type.

cp:
2017-10-06  Bernd 

Re: [PATCH] Add a warning for invalid function casts

[Martin Sebor]

On 10/09/2017 11:50 AM, Bernd Edlinger wrote:

On 10/09/17 18:44, Martin Sebor wrote:

On 10/07/2017 10:48 AM, Bernd Edlinger wrote:

Hi!

I think I have now something useful, it has a few more heuristics
added, to reduce the number of false-positives so that it
is able to find real bugs, for instance in openssl it triggers
at a function cast which has already a TODO on it.

The heuristics are:
- handle void (*)(void) as a wild-card function type.
- ignore volatile, const qualifiers on parameters/return.
- handle any pointers as equivalent.
- handle integral types, enums, and booleans of same precision
   and signedness as equivalent.
- stop parameter validation at the first "...".


These sound quite reasonable to me.  I have a reservation about
just one of them, and some comments about other aspects of the
warning.  Sorry if this seems like a lot.  I'm hoping you'll
find the feedback constructive.

I don't think using void(*)(void) to suppress the warning is
a robust solution because it's not safe to call a function that
takes arguments through such a pointer (especially not if one
or more of the arguments is a pointer).  Depending on the ABI,
calling a function that expects arguments with none could also
mess up the stack as the callee may pop arguments that were
never passed to it.



This is of course only a heuristic, and if there is no warning
that does not mean any guarantee that there can't be a problem
at runtime.  The heuristic is only meant to separate the
bad from the very bad type-cast.  In my personal opinion there
is not a single good type cast.


I agree.  Since the warning uses one kind of a cast as an escape
mechanism from the checking it should be one whose result can
the most likely be used to call the function without undefined
behavior.

Since it's possible to call any function through a pointer to
a function with no arguments (simply by providing arguments of
matching types) it's a reasonable candidate.

On the other hand, since it is not safe to call an arbitrary
function through void (*)(void), it's not as good a candidate.

Another reason why I think a protoype-less function is a good
choice is because the alias and ifunc attributes already use it
as an escape mechanism from their type incompatibility warning.

Martin

Re: [PATCH] Add a warning for invalid function casts

[Bernd Edlinger]

On 10/09/17 18:44, Martin Sebor wrote:
> On 10/07/2017 10:48 AM, Bernd Edlinger wrote:
>> Hi!
>>
>> I think I have now something useful, it has a few more heuristics
>> added, to reduce the number of false-positives so that it
>> is able to find real bugs, for instance in openssl it triggers
>> at a function cast which has already a TODO on it.
>>
>> The heuristics are:
>> - handle void (*)(void) as a wild-card function type.
>> - ignore volatile, const qualifiers on parameters/return.
>> - handle any pointers as equivalent.
>> - handle integral types, enums, and booleans of same precision
>>    and signedness as equivalent.
>> - stop parameter validation at the first "...".
> 
> These sound quite reasonable to me.  I have a reservation about
> just one of them, and some comments about other aspects of the
> warning.  Sorry if this seems like a lot.  I'm hoping you'll
> find the feedback constructive.
> 
> I don't think using void(*)(void) to suppress the warning is
> a robust solution because it's not safe to call a function that
> takes arguments through such a pointer (especially not if one
> or more of the arguments is a pointer).  Depending on the ABI,
> calling a function that expects arguments with none could also
> mess up the stack as the callee may pop arguments that were
> never passed to it.
> 

This is of course only a heuristic, and if there is no warning
that does not mean any guarantee that there can't be a problem
at runtime.  The heuristic is only meant to separate the
bad from the very bad type-cast.  In my personal opinion there
is not a single good type cast.

> Instead, I think the warning should be suppressed for casts to
> function types without a prototype.  Calling those is (or should
> for the most part be) safe and they are the natural way to express
> that we don't care about type safety.
> 
> Let me also clarify that I understand bullet 4 correctly.
> In my tests the warning triggers on enum/integral/boolean
> incompatibilities that the text above suggests should be accepted.
>   E.g.:
> 
>    typedef enum E { e } E;
>    E f (void);
> 
>    typedef int F (void);
> 
>    F *pf = (F *)f;   // -Wcast-function-type
> 
> Is the warning here intended?  (My reading of the documentation
> suggests it's not.)
> 

Aehm no, that is unintentional, thanks for testing...

It looks like the warning does not trigger with
typedef unsigned int F (void);

But this enum should promote to int, likewise for _Bool,
So I think this should be fixable.


> In testing the warning in C++, I noticed it's not issued for
> casts between incompatible pointers to member functions, or for
> casts between member functions to ordinary functions (those are
> diagnosed with -Wpedantic
> 
>    struct S { void foo (int*); };
> 
>    typedef void (S::*MF)(int);
>    typedef void F (int*);
> 
>    MF pmf = (MF)::foo;   // no warning
>    F *pf = (F*)::foo;    // -Wpedantic only
> 
> These both look like they would be worth diagnosing under the new
> option (the second one looks like an opportunity to provide
> a dedicated option to control the existing pedantic warning).
> 

Yes I agree.

I think all pointer-to member function casts where the types
are different should warn, although I don't have seen any of that
crap so far.


>> I cannot convince myself to handle uintptr_t and pointers as
>> equivalent.  It is possible that targets like m68k have
>> an ABI where uintptr_t and void* are different as return values
>> but are identical as parameter values.
>>
>> IMHO adding an exception for uintptr_t vs. pointer as parameters
>> could easily prevent detection of real bugs.  Even if it is safe
>> for all targets.
>>
>> However it happens: Examples are the libiberty splay-tree functions,
>> and also one single place in linux, where an argument of type
>> "long int" is used to call a timer function with a pointer
>> argument.  Note, linux does not enable -Wextra.
>>
>>
>> Patch was bootstrapped and reg-tested on x86_64-pc-linux-gnu.
>> Is it OK for trunk?
> 
> A few comments on the documentation:
> 
>    When one of the function types uses variable arguments like this
>    @code{int f(...);}, then only the return value and the parameters
>    before the @code{...} are checked,
> 
> Although G++ accepts 'int f(...)' since GCC does not I would suggest
> to avoid showing the prototype in the descriptive text and instead
> refer to "functions taking variable arguments."   Also, it's the
> types of the arguments that are considered (not the value).  With
> that I would suggest rewording the sentence along these lines:
>  >    In a cast involving a function types with a variable argument
>    list only the types of initial arguments that are provided are
>    considered.
> 
> The sentence
> 
>    Any benign differences in integral types are ignored...
> 
> leaves open the question of what's considered benign.  In my view,
> if pointer types are ignored (which is reasonable as we discussed
> but which can lead to serious 

Re: [PATCH] Add a warning for invalid function casts

[Martin Sebor]

On 10/07/2017 10:48 AM, Bernd Edlinger wrote:

Hi!

I think I have now something useful, it has a few more heuristics
added, to reduce the number of false-positives so that it
is able to find real bugs, for instance in openssl it triggers
at a function cast which has already a TODO on it.

The heuristics are:
- handle void (*)(void) as a wild-card function type.
- ignore volatile, const qualifiers on parameters/return.
- handle any pointers as equivalent.
- handle integral types, enums, and booleans of same precision
   and signedness as equivalent.
- stop parameter validation at the first "...".


These sound quite reasonable to me.  I have a reservation about
just one of them, and some comments about other aspects of the
warning.  Sorry if this seems like a lot.  I'm hoping you'll
find the feedback constructive.

I don't think using void(*)(void) to suppress the warning is
a robust solution because it's not safe to call a function that
takes arguments through such a pointer (especially not if one
or more of the arguments is a pointer).  Depending on the ABI,
calling a function that expects arguments with none could also
mess up the stack as the callee may pop arguments that were
never passed to it.

Instead, I think the warning should be suppressed for casts to
function types without a prototype.  Calling those is (or should
for the most part be) safe and they are the natural way to express
that we don't care about type safety.

Let me also clarify that I understand bullet 4 correctly.
In my tests the warning triggers on enum/integral/boolean
incompatibilities that the text above suggests should be accepted.
 E.g.:

  typedef enum E { e } E;
  E f (void);

  typedef int F (void);

  F *pf = (F *)f;   // -Wcast-function-type

Is the warning here intended?  (My reading of the documentation
suggests it's not.)

In testing the warning in C++, I noticed it's not issued for
casts between incompatible pointers to member functions, or for
casts between member functions to ordinary functions (those are
diagnosed with -Wpedantic

  struct S { void foo (int*); };

  typedef void (S::*MF)(int);
  typedef void F (int*);

  MF pmf = (MF)::foo;   // no warning
  F *pf = (F*)::foo;// -Wpedantic only

These both look like they would be worth diagnosing under the new
option (the second one looks like an opportunity to provide
a dedicated option to control the existing pedantic warning).


I cannot convince myself to handle uintptr_t and pointers as
equivalent.  It is possible that targets like m68k have
an ABI where uintptr_t and void* are different as return values
but are identical as parameter values.

IMHO adding an exception for uintptr_t vs. pointer as parameters
could easily prevent detection of real bugs.  Even if it is safe
for all targets.

However it happens: Examples are the libiberty splay-tree functions,
and also one single place in linux, where an argument of type
"long int" is used to call a timer function with a pointer
argument.  Note, linux does not enable -Wextra.


Patch was bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?


A few comments on the documentation:

  When one of the function types uses variable arguments like this
  @code{int f(...);}, then only the return value and the parameters
  before the @code{...} are checked,

Although G++ accepts 'int f(...)' since GCC does not I would suggest
to avoid showing the prototype in the descriptive text and instead
refer to "functions taking variable arguments."   Also, it's the
types of the arguments that are considered (not the value).  With
that I would suggest rewording the sentence along these lines:

  In a cast involving a function types with a variable argument
  list only the types of initial arguments that are provided are
  considered.

The sentence

  Any benign differences in integral types are ignored...

leaves open the question of what's considered benign.  In my view,
if pointer types are ignored (which is reasonable as we discussed
but which can lead to serious problems) it seems that that
signed/unsigned differences should also be considered benign.
 The consequences of those differences seem considerably less
dangerous than calling a function that takes an char* with an int*
argument.

Regarding qualifiers, unless some types qualifiers are not ignored
(e.g., _Atomic and restrict) I would suggest to correct the sentence
that mentions const and volatile to simply refer to "type qualifiers"
instead to make it clear that no qualifiers are considered.

Martin

Re: [RFA] [PATCH] Add a warning for invalid function casts

[Eric Gallager]

On Fri, Oct 6, 2017 at 2:06 PM, Bernd Edlinger
 wrote:
> On 10/06/17 17:43, Martin Sebor wrote:
>> On 10/06/2017 07:25 AM, Bernd Edlinger wrote:
>>> On 10/05/17 18:16, Martin Sebor wrote:
 In my (very quick) tests the warning appears to trigger on all
 strictly incompatible conversions, even if they are otherwise
 benign, such as:

int f (const int*);
typedef int F (int*);

F* pf1 = f;// -Wincompatible-pointer-types
F* pf2 = (F*)f;// -Wcast-function-type

 Likewise by:

int f (signed char);
typedef int F (unsigned char);

F* pf = (F*)f;// -Wcast-function-type

 I'd expect these conversions to be useful and would view warning
 for them with -Wextra as excessive.  In fact, I'm not sure I see
 the benefit of warning on these casts under any circumstances.

>>>
>>> Well, while the first example should be safe,
>>> the second one is probably not safe:
>>>
>>> Because the signed and unsigned char are promoted to int,
>>> by the ABI but one is in the range -128..127 while the
>>> other is in the range 0..255, right?
>>
>> Right.  The cast is always safe but whether or not a call to such
>> a function through the incompatible pointer is also safe depends
>> on the definition of the function (and on the caller).  If the
>> function uses just the low bits of the argument then it's most
>> likely fine for any argument.  If the caller only calls it with
>> values in the 7-bit range (e.g., the ASCII subset) then it's also
>> fine.  Otherwise there's the potential for the problem you pointed
>> out.  (Similarly, if in the first example I gave the cast added
>> constness to the argument rather than removing it and the function
>> modified the pointed-to object calling it through the incompatible
>> pointer on a constant object would also be unsafe.)
>>
>> Another class of cases to consider are casts between functions
>> taking pointers to different but related structs.  Code like this
>> could be written to mimic C++ calling a base class function on
>> a derived object.
>>
>>struct Base { ... };
>>struct Derived { Base b; ... };
>>
>>typedef void F (Derived*);
>>
>>void foo (Base*);
>>
>>F* pf = (F*)foo;
>>
>
> Hmm, yes.
>
> I start to believe, that this warning should treat all pointers
> as equivalent, but everything else need to be of the same type.
> That would at least cover the majority of all "safe" use cases.
>
> And I need a way to by-pass the warning with a generic function
> pointer type.  uintptr_t is not the right choice, as you pointed
> out already.
>
> But I also see problems with "int (*) ()" as a escape mechanism
> because this declaration creates a warning in C with
> -Wstrict-prototypes, and in C++ this syntax means "int (*) (void)"
> while the C++ type "int (*) (...)" is rejected by the C front end.
>

Note also that besides -Wstrict-prototypes, there's also a warning
from -Wold-style-definition if using it for a definition instead of a
declaration. Also, if unprototyped functions are completely removed
from C as Joseph mentioned in another branch of this thread, the code
would be completely invalid:
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00257.html

> I start to believe that the type "void (*) (void)" is better suited for
> this purpose, and it is already used in many programs as a type-less
> wildcard function type.  I see examples in libgo and libffi at least.
>
>
>
> Bernd.

Re: [RFA] [PATCH] Add a warning for invalid function casts

[Eric Gallager]

On Fri, Oct 6, 2017 at 4:37 PM, Martin Sebor  wrote:
> On 10/06/2017 12:06 PM, Bernd Edlinger wrote:
>>
>> On 10/06/17 17:43, Martin Sebor wrote:
>>>
>>> On 10/06/2017 07:25 AM, Bernd Edlinger wrote:

 On 10/05/17 18:16, Martin Sebor wrote:
>
> In my (very quick) tests the warning appears to trigger on all
> strictly incompatible conversions, even if they are otherwise
> benign, such as:
>
>int f (const int*);
>typedef int F (int*);
>
>F* pf1 = f;// -Wincompatible-pointer-types
>F* pf2 = (F*)f;// -Wcast-function-type
>
> Likewise by:
>
>int f (signed char);
>typedef int F (unsigned char);
>
>F* pf = (F*)f;// -Wcast-function-type
>
> I'd expect these conversions to be useful and would view warning
> for them with -Wextra as excessive.  In fact, I'm not sure I see
> the benefit of warning on these casts under any circumstances.
>

 Well, while the first example should be safe,
 the second one is probably not safe:

 Because the signed and unsigned char are promoted to int,
 by the ABI but one is in the range -128..127 while the
 other is in the range 0..255, right?
>>>
>>>
>>> Right.  The cast is always safe but whether or not a call to such
>>> a function through the incompatible pointer is also safe depends
>>> on the definition of the function (and on the caller).  If the
>>> function uses just the low bits of the argument then it's most
>>> likely fine for any argument.  If the caller only calls it with
>>> values in the 7-bit range (e.g., the ASCII subset) then it's also
>>> fine.  Otherwise there's the potential for the problem you pointed
>>> out.  (Similarly, if in the first example I gave the cast added
>>> constness to the argument rather than removing it and the function
>>> modified the pointed-to object calling it through the incompatible
>>> pointer on a constant object would also be unsafe.)
>>>
>>> Another class of cases to consider are casts between functions
>>> taking pointers to different but related structs.  Code like this
>>> could be written to mimic C++ calling a base class function on
>>> a derived object.
>>>
>>>struct Base { ... };
>>>struct Derived { Base b; ... };
>>>
>>>typedef void F (Derived*);
>>>
>>>void foo (Base*);
>>>
>>>F* pf = (F*)foo;
>>>
>>
>> Hmm, yes.
>>
>> I start to believe, that this warning should treat all pointers
>> as equivalent, but everything else need to be of the same type.
>> That would at least cover the majority of all "safe" use cases.
>
>
> Perhaps basing the warning on some form of structural equivalence
> between function arguments might be useful.  For instance, in
> ILP32, casting between 'int foo (int)' and 'long foo (long)' and
> calling the function is probably generally considered safe (even
> though it's undefined by the language) and works as people expect
> so avoiding the warning there would help keep the false positive
> rate down. (Something like this might also work for the kernel
> alias macros.)
>
> Similarly, casting between a function that returns a scalar smaller
> than int and int and then calling it is probably safe (or maybe
> even long, depending on the ABI).
>
> Casting a function returning a value to one returning void and
> calling it through the result should always be safe.
>
> I would also suggest to consider disregarding qualifiers as those
> are often among the reasons for intentional casts (e.g., when
> mixing a legacy API and a more modern const-correct one).
>
> Casts are also not uncommon between variadic and ordinary function
> types so some heuristic might be appropriate there.
>
>>
>> And I need a way to by-pass the warning with a generic function
>> pointer type.  uintptr_t is not the right choice, as you pointed
>> out already.
>>
>> But I also see problems with "int (*) ()" as a escape mechanism
>> because this declaration creates a warning in C with
>> -Wstrict-prototypes, and in C++ this syntax means "int (*) (void)"
>> while the C++ type "int (*) (...)" is rejected by the C front end.
>
>
> I wouldn't consider it a problem if the suppression mechanism were
> different between languages.  Most such casts are going to be in
> source files (as opposed to C headers) so it should be fine to use
> each language's unique form of function without a prototype.
>
> Martin

Some codebases attempt to be compilable as both C and C++, whether it
be by using -Wc++-compat, or having options to compile with either the
C compiler or C++ compiler. In such cases, I'd prefer to keep the
amounts of "#ifdef __cplusplus" required to a minimum; a suppression
mechanic that works the same between languages would be much
preferred.

[PATCH] Add a warning for invalid function casts

[Bernd Edlinger]

Hi!

I think I have now something useful, it has a few more heuristics
added, to reduce the number of false-positives so that it
is able to find real bugs, for instance in openssl it triggers
at a function cast which has already a TODO on it.

The heuristics are:
- handle void (*)(void) as a wild-card function type.
- ignore volatile, const qualifiers on parameters/return.
- handle any pointers as equivalent.
- handle integral types, enums, and booleans of same precision
   and signedness as equivalent.
- stop parameter validation at the first "...".

I cannot convince myself to handle uintptr_t and pointers as
equivalent.  It is possible that targets like m68k have
an ABI where uintptr_t and void* are different as return values
but are identical as parameter values.

IMHO adding an exception for uintptr_t vs. pointer as parameters
could easily prevent detection of real bugs.  Even if it is safe
for all targets.

However it happens: Examples are the libiberty splay-tree functions,
and also one single place in linux, where an argument of type
"long int" is used to call a timer function with a pointer
argument.  Note, linux does not enable -Wextra.


Patch was bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?


Thanks
Bernd.
gcc:
2017-10-06  Bernd Edlinger  

* doc/invoke.texi: Document -Wcast-function-type.
* recog.h (stored_funcptr): Change signature.
* tree-dump.c (dump_node): Avoid warning.
* typed-splay-tree.h (typed_splay_tree): Avoid warning.

libcpp:
2017-10-06  Bernd Edlinger  

* internal.h (maybe_print_line): Change signature.

c-family:
2017-10-06  Bernd Edlinger  

* c.opt (Wcast-function-type): New warning option.
* c-lex.c (get_fileinfo): Avoid warning.
* c-ppoutput.c (scan_translation_unit_directives_only): Remove cast.

c:
2017-10-06  Bernd Edlinger  

* c-typeck.c (c_abi_equiv_type_p, c_safe_function_type_cast_p): New.
(build_c_cast): Implement -Wcast_function_type.

cp:
2017-10-06  Bernd Edlinger  

* decl2.c (start_static_storage_duration_function): Avoid warning.
* typeck.c (cxx_abi_equiv_type_p, cxx_safe_function_type_cast_p): New.
(build_reinterpret_cast_1): Implement -Wcast_function_type.

testsuite:
2017-10-06  Bernd Edlinger  

* c-c++-common/Wcast-function-type.c: New test.
Index: gcc/c/c-typeck.c
===
--- gcc/c/c-typeck.c	(revision 253493)
+++ gcc/c/c-typeck.c	(working copy)
@@ -5474,6 +5474,52 @@ handle_warn_cast_qual (location_t loc, tree type,
   while (TREE_CODE (in_type) == POINTER_TYPE);
 }
 
+/* Heuristic check if two parameter types can be considered ABI-equivalent.  */
+
+static bool
+c_abi_equiv_type_p (tree t1, tree t2)
+{
+  t1 = TYPE_MAIN_VARIANT (t1);
+  t2 = TYPE_MAIN_VARIANT (t2);
+
+  if (TREE_CODE (t1) == POINTER_TYPE
+  && TREE_CODE (t2) == POINTER_TYPE)
+return true;
+
+  if (INTEGRAL_TYPE_P (t1)
+  && INTEGRAL_TYPE_P (t2)
+  && TYPE_PRECISION (t1) == TYPE_PRECISION (t2)
+  && TYPE_UNSIGNED (t1) == TYPE_UNSIGNED (t2))
+return true;
+
+  return comptypes (t1, t2);
+}
+
+/* Check if a type cast between two function types can be considered safe.  */
+
+static bool
+c_safe_function_type_cast_p (tree t1, tree t2)
+{
+  if (TREE_TYPE (t1) == void_type_node &&
+  TYPE_ARG_TYPES (t1) == void_list_node)
+return true;
+
+  if (TREE_TYPE (t2) == void_type_node &&
+  TYPE_ARG_TYPES (t2) == void_list_node)
+return true;
+
+  if (!c_abi_equiv_type_p (TREE_TYPE (t1), TREE_TYPE (t2)))
+return false;
+
+  for (t1 = TYPE_ARG_TYPES (t1), t2 = TYPE_ARG_TYPES (t2);
+   t1 && t2;
+   t1 = TREE_CHAIN (t1), t2 = TREE_CHAIN (t2))
+if (!c_abi_equiv_type_p (TREE_VALUE (t1), TREE_VALUE (t2)))
+  return false;
+
+  return true;
+}
+
 /* Build an expression representing a cast to type TYPE of expression EXPR.
LOC is the location of the cast-- typically the open paren of the cast.  */
 
@@ -5667,6 +5713,16 @@ build_c_cast (location_t loc, tree type, tree expr
 	pedwarn (loc, OPT_Wpedantic, "ISO C forbids "
 		 "conversion of object pointer to function pointer type");
 
+  if (TREE_CODE (type) == POINTER_TYPE
+	  && TREE_CODE (otype) == POINTER_TYPE
+	  && TREE_CODE (TREE_TYPE (type)) == FUNCTION_TYPE
+	  && TREE_CODE (TREE_TYPE (otype)) == FUNCTION_TYPE
+	  && !c_safe_function_type_cast_p (TREE_TYPE (type),
+	   TREE_TYPE (otype)))
+	warning_at (loc, OPT_Wcast_function_type,
+		"cast between incompatible function types"
+		" from %qT to %qT", otype, type);
+
   ovalue = value;
   value = convert (type, value);
 
Index: gcc/c-family/c-lex.c
===
--- gcc/c-family/c-lex.c	(revision 

Re: [RFA] [PATCH] Add a warning for invalid function casts

[Bernd Edlinger]

On 10/06/17 22:50, Jeff Law wrote:
> On 10/06/2017 09:43 AM, Martin Sebor wrote:
>> On 10/06/2017 07:25 AM, Bernd Edlinger wrote:
>>> On 10/05/17 18:16, Martin Sebor wrote:
 In my (very quick) tests the warning appears to trigger on all
 strictly incompatible conversions, even if they are otherwise
 benign, such as:

     int f (const int*);
     typedef int F (int*);

     F* pf1 = f;    // -Wincompatible-pointer-types
     F* pf2 = (F*)f;    // -Wcast-function-type

 Likewise by:

     int f (signed char);
     typedef int F (unsigned char);

     F* pf = (F*)f;    // -Wcast-function-type

 I'd expect these conversions to be useful and would view warning
 for them with -Wextra as excessive.  In fact, I'm not sure I see
 the benefit of warning on these casts under any circumstances.

>>>
>>> Well, while the first example should be safe,
>>> the second one is probably not safe:
>>>
>>> Because the signed and unsigned char are promoted to int,
>>> by the ABI but one is in the range -128..127 while the
>>> other is in the range 0..255, right?
>>
>> Right.  The cast is always safe but whether or not a call to such
>> a function through the incompatible pointer is also safe depends
>> on the definition of the function (and on the caller).  If the
>> function uses just the low bits of the argument then it's most
>> likely fine for any argument.  If the caller only calls it with
>> values in the 7-bit range (e.g., the ASCII subset) then it's also
>> fine.  Otherwise there's the potential for the problem you pointed
>> out.  (Similarly, if in the first example I gave the cast added
>> constness to the argument rather than removing it and the function
>> modified the pointed-to object calling it through the incompatible
>> pointer on a constant object would also be unsafe.)
>>
>> Another class of cases to consider are casts between functions
>> taking pointers to different but related structs.  Code like this
>> could be written to mimic C++ calling a base class function on
>> a derived object.
>>
>>    struct Base { ... };
>>    struct Derived { Base b; ... };
>>
>>    typedef void F (Derived*);
>>
>>    void foo (Base*);
>>
>>    F* pf = (F*)foo;
> Yea.  And one might even find such code in BFD.  It certainly mimicks
> C++ base and derived classes using C, so it has significant potential to
> have this kind of code.
> jeff
> 

Yes, absolutely.

This use case makes up 99% of all places where I saw the warning until
now.  I will try to ignore all pointer types and see how that works out
on some code bases I have access to.

When that works as expected we should be able to see what heuristics
need to be added next.

FYI I have attached what I am currently bootstrapping.


Bernd.
gcc:
2017-10-06  Bernd Edlinger  

* doc/invoke.texi: Document -Wcast-function-type.
* recog.h (stored_funcptr): Change signature.
* tree-dump.c (dump_node): Avoid warning.
* typed-splay-tree.h (typed_splay_tree): Avoid warning.

libcpp:
2017-10-06  Bernd Edlinger  

* internal.h (maybe_print_line): Change signature.

c-family:
2017-10-06  Bernd Edlinger  

* c.opt (Wcast-function-type): New warning option.
* c-lex.c (get_fileinfo): Avoid warning.
* c-ppoutput.c (scan_translation_unit_directives_only): Remove cast.

c:
2017-10-06  Bernd Edlinger  

* c-typeck.c (c_safe_function_type_cast_p): New helper function.
(build_c_cast): Implement -Wcast_function_type.

cp:
2017-10-06  Bernd Edlinger  

* decl2.c (start_static_storage_duration_function): Aboid warning.
* typeck.c (+cxx_safe_function_type_cast_p): New helper function.
(build_reinterpret_cast_1): Implement -Wcast_function_type.

testsuite:
2017-10-06  Bernd Edlinger  

* c-c++-common/Wcast-function-type.c: New test.
Index: gcc/c/c-typeck.c
===
--- gcc/c/c-typeck.c	(revision 253493)
+++ gcc/c/c-typeck.c	(working copy)
@@ -5474,6 +5474,36 @@ handle_warn_cast_qual (location_t loc, tree type,
   while (TREE_CODE (in_type) == POINTER_TYPE);
 }
 
+/* Check if a type cast between two function types can be considered safe.  */
+
+static bool
+c_safe_function_type_cast_p (tree t1, tree t2)
+{
+  if (TREE_TYPE (t1) == void_type_node &&
+  TYPE_ARG_TYPES (t1) == void_list_node)
+return true;
+
+  if (TREE_TYPE (t2) == void_type_node &&
+  TYPE_ARG_TYPES (t2) == void_list_node)
+return true;
+
+  if (!comptypes (TREE_TYPE (t1), TREE_TYPE (t2)))
+return false;
+
+  for (t1 = TYPE_ARG_TYPES (t1), t2 = TYPE_ARG_TYPES (t2);
+   t1 && t2;
+   t1 = TREE_CHAIN (t1), t2 = TREE_CHAIN (t2))
+{
+  if (TREE_CODE (TREE_VALUE (t1)) == POINTER_TYPE
+	

Re: [RFA] [PATCH] Add a warning for invalid function casts

[Jeff Law]

On 10/06/2017 09:43 AM, Martin Sebor wrote:
> On 10/06/2017 07:25 AM, Bernd Edlinger wrote:
>> On 10/05/17 18:16, Martin Sebor wrote:
>>> In my (very quick) tests the warning appears to trigger on all
>>> strictly incompatible conversions, even if they are otherwise
>>> benign, such as:
>>>
>>>    int f (const int*);
>>>    typedef int F (int*);
>>>
>>>    F* pf1 = f;    // -Wincompatible-pointer-types
>>>    F* pf2 = (F*)f;    // -Wcast-function-type
>>>
>>> Likewise by:
>>>
>>>    int f (signed char);
>>>    typedef int F (unsigned char);
>>>
>>>    F* pf = (F*)f;    // -Wcast-function-type
>>>
>>> I'd expect these conversions to be useful and would view warning
>>> for them with -Wextra as excessive.  In fact, I'm not sure I see
>>> the benefit of warning on these casts under any circumstances.
>>>
>>
>> Well, while the first example should be safe,
>> the second one is probably not safe:
>>
>> Because the signed and unsigned char are promoted to int,
>> by the ABI but one is in the range -128..127 while the
>> other is in the range 0..255, right?
> 
> Right.  The cast is always safe but whether or not a call to such
> a function through the incompatible pointer is also safe depends
> on the definition of the function (and on the caller).  If the
> function uses just the low bits of the argument then it's most
> likely fine for any argument.  If the caller only calls it with
> values in the 7-bit range (e.g., the ASCII subset) then it's also
> fine.  Otherwise there's the potential for the problem you pointed
> out.  (Similarly, if in the first example I gave the cast added
> constness to the argument rather than removing it and the function
> modified the pointed-to object calling it through the incompatible
> pointer on a constant object would also be unsafe.)
> 
> Another class of cases to consider are casts between functions
> taking pointers to different but related structs.  Code like this
> could be written to mimic C++ calling a base class function on
> a derived object.
> 
>   struct Base { ... };
>   struct Derived { Base b; ... };
> 
>   typedef void F (Derived*);
> 
>   void foo (Base*);
> 
>   F* pf = (F*)foo;
Yea.  And one might even find such code in BFD.  It certainly mimicks
C++ base and derived classes using C, so it has significant potential to
have this kind of code.
jeff

Re: [RFA] [PATCH] Add a warning for invalid function casts

[Jeff Law]

On 10/05/2017 03:47 PM, Joseph Myers wrote:
> On Thu, 5 Oct 2017, Bernd Edlinger wrote:
> 
>> Maybe it would be good to not warn in type-casts, when they can be
>> assumed to be safe, for instance
>> void* <-> any pointer (parameter or result),
>> uintptr_t <-> any int, any pointer (parameter or result),
>> void (*) (void) and void (*) (...) <-> any function pointer.
> 
> Well, void * and uintptr_t aren't necessarily interchangable at the ABI 
> level.  At least, the m68k ABI returns integers in %d0 and pointers in 
> %a0; I don't know if any other ABIs have that peculiarity.
> 
The mn103 (live) and mn102 (dead) probably do.  But my memory is getting
fuzzy on those.

jeff

Re: [RFA] [PATCH] Add a warning for invalid function casts

[Martin Sebor]

On 10/06/2017 12:06 PM, Bernd Edlinger wrote:

On 10/06/17 17:43, Martin Sebor wrote:

On 10/06/2017 07:25 AM, Bernd Edlinger wrote:

On 10/05/17 18:16, Martin Sebor wrote:

In my (very quick) tests the warning appears to trigger on all
strictly incompatible conversions, even if they are otherwise
benign, such as:

   int f (const int*);
   typedef int F (int*);

   F* pf1 = f;// -Wincompatible-pointer-types
   F* pf2 = (F*)f;// -Wcast-function-type

Likewise by:

   int f (signed char);
   typedef int F (unsigned char);

   F* pf = (F*)f;// -Wcast-function-type

I'd expect these conversions to be useful and would view warning
for them with -Wextra as excessive.  In fact, I'm not sure I see
the benefit of warning on these casts under any circumstances.



Well, while the first example should be safe,
the second one is probably not safe:

Because the signed and unsigned char are promoted to int,
by the ABI but one is in the range -128..127 while the
other is in the range 0..255, right?


Right.  The cast is always safe but whether or not a call to such
a function through the incompatible pointer is also safe depends
on the definition of the function (and on the caller).  If the
function uses just the low bits of the argument then it's most
likely fine for any argument.  If the caller only calls it with
values in the 7-bit range (e.g., the ASCII subset) then it's also
fine.  Otherwise there's the potential for the problem you pointed
out.  (Similarly, if in the first example I gave the cast added
constness to the argument rather than removing it and the function
modified the pointed-to object calling it through the incompatible
pointer on a constant object would also be unsafe.)

Another class of cases to consider are casts between functions
taking pointers to different but related structs.  Code like this
could be written to mimic C++ calling a base class function on
a derived object.

   struct Base { ... };
   struct Derived { Base b; ... };

   typedef void F (Derived*);

   void foo (Base*);

   F* pf = (F*)foo;



Hmm, yes.

I start to believe, that this warning should treat all pointers
as equivalent, but everything else need to be of the same type.
That would at least cover the majority of all "safe" use cases.


Perhaps basing the warning on some form of structural equivalence
between function arguments might be useful.  For instance, in
ILP32, casting between 'int foo (int)' and 'long foo (long)' and
calling the function is probably generally considered safe (even
though it's undefined by the language) and works as people expect
so avoiding the warning there would help keep the false positive
rate down. (Something like this might also work for the kernel
alias macros.)

Similarly, casting between a function that returns a scalar smaller
than int and int and then calling it is probably safe (or maybe
even long, depending on the ABI).

Casting a function returning a value to one returning void and
calling it through the result should always be safe.

I would also suggest to consider disregarding qualifiers as those
are often among the reasons for intentional casts (e.g., when
mixing a legacy API and a more modern const-correct one).

Casts are also not uncommon between variadic and ordinary function
types so some heuristic might be appropriate there.



And I need a way to by-pass the warning with a generic function
pointer type.  uintptr_t is not the right choice, as you pointed
out already.

But I also see problems with "int (*) ()" as a escape mechanism
because this declaration creates a warning in C with
-Wstrict-prototypes, and in C++ this syntax means "int (*) (void)"
while the C++ type "int (*) (...)" is rejected by the C front end.


I wouldn't consider it a problem if the suppression mechanism were
different between languages.  Most such casts are going to be in
source files (as opposed to C headers) so it should be fine to use
each language's unique form of function without a prototype.

Martin

Re: [RFA] [PATCH] Add a warning for invalid function casts

[Bernd Edlinger]

On 10/06/17 17:43, Martin Sebor wrote:
> On 10/06/2017 07:25 AM, Bernd Edlinger wrote:
>> On 10/05/17 18:16, Martin Sebor wrote:
>>> In my (very quick) tests the warning appears to trigger on all
>>> strictly incompatible conversions, even if they are otherwise
>>> benign, such as:
>>>
>>>    int f (const int*);
>>>    typedef int F (int*);
>>>
>>>    F* pf1 = f;    // -Wincompatible-pointer-types
>>>    F* pf2 = (F*)f;    // -Wcast-function-type
>>>
>>> Likewise by:
>>>
>>>    int f (signed char);
>>>    typedef int F (unsigned char);
>>>
>>>    F* pf = (F*)f;    // -Wcast-function-type
>>>
>>> I'd expect these conversions to be useful and would view warning
>>> for them with -Wextra as excessive.  In fact, I'm not sure I see
>>> the benefit of warning on these casts under any circumstances.
>>>
>>
>> Well, while the first example should be safe,
>> the second one is probably not safe:
>>
>> Because the signed and unsigned char are promoted to int,
>> by the ABI but one is in the range -128..127 while the
>> other is in the range 0..255, right?
> 
> Right.  The cast is always safe but whether or not a call to such
> a function through the incompatible pointer is also safe depends
> on the definition of the function (and on the caller).  If the
> function uses just the low bits of the argument then it's most
> likely fine for any argument.  If the caller only calls it with
> values in the 7-bit range (e.g., the ASCII subset) then it's also
> fine.  Otherwise there's the potential for the problem you pointed
> out.  (Similarly, if in the first example I gave the cast added
> constness to the argument rather than removing it and the function
> modified the pointed-to object calling it through the incompatible
> pointer on a constant object would also be unsafe.)
> 
> Another class of cases to consider are casts between functions
> taking pointers to different but related structs.  Code like this
> could be written to mimic C++ calling a base class function on
> a derived object.
> 
>    struct Base { ... };
>    struct Derived { Base b; ... };
> 
>    typedef void F (Derived*);
> 
>    void foo (Base*);
> 
>    F* pf = (F*)foo;
> 

Hmm, yes.

I start to believe, that this warning should treat all pointers
as equivalent, but everything else need to be of the same type.
That would at least cover the majority of all "safe" use cases.

And I need a way to by-pass the warning with a generic function
pointer type.  uintptr_t is not the right choice, as you pointed
out already.

But I also see problems with "int (*) ()" as a escape mechanism
because this declaration creates a warning in C with
-Wstrict-prototypes, and in C++ this syntax means "int (*) (void)"
while the C++ type "int (*) (...)" is rejected by the C front end.

I start to believe that the type "void (*) (void)" is better suited for
this purpose, and it is already used in many programs as a type-less
wildcard function type.  I see examples in libgo and libffi at least.



Bernd.

Re: [RFA] [PATCH] Add a warning for invalid function casts

[Martin Sebor]

On 10/06/2017 07:25 AM, Bernd Edlinger wrote:

On 10/05/17 18:16, Martin Sebor wrote:

In my (very quick) tests the warning appears to trigger on all
strictly incompatible conversions, even if they are otherwise
benign, such as:

   int f (const int*);
   typedef int F (int*);

   F* pf1 = f;// -Wincompatible-pointer-types
   F* pf2 = (F*)f;// -Wcast-function-type

Likewise by:

   int f (signed char);
   typedef int F (unsigned char);

   F* pf = (F*)f;// -Wcast-function-type

I'd expect these conversions to be useful and would view warning
for them with -Wextra as excessive.  In fact, I'm not sure I see
the benefit of warning on these casts under any circumstances.



Well, while the first example should be safe,
the second one is probably not safe:

Because the signed and unsigned char are promoted to int,
by the ABI but one is in the range -128..127 while the
other is in the range 0..255, right?


Right.  The cast is always safe but whether or not a call to such
a function through the incompatible pointer is also safe depends
on the definition of the function (and on the caller).  If the
function uses just the low bits of the argument then it's most
likely fine for any argument.  If the caller only calls it with
values in the 7-bit range (e.g., the ASCII subset) then it's also
fine.  Otherwise there's the potential for the problem you pointed
out.  (Similarly, if in the first example I gave the cast added
constness to the argument rather than removing it and the function
modified the pointed-to object calling it through the incompatible
pointer on a constant object would also be unsafe.)

Another class of cases to consider are casts between functions
taking pointers to different but related structs.  Code like this
could be written to mimic C++ calling a base class function on
a derived object.

  struct Base { ... };
  struct Derived { Base b; ... };

  typedef void F (Derived*);

  void foo (Base*);

  F* pf = (F*)foo;

Martin

Re: [RFA] [PATCH] Add a warning for invalid function casts

[Bernd Edlinger]

On 10/05/17 18:16, Martin Sebor wrote:
> In my (very quick) tests the warning appears to trigger on all
> strictly incompatible conversions, even if they are otherwise
> benign, such as:
> 
>    int f (const int*);
>    typedef int F (int*);
> 
>    F* pf1 = f;    // -Wincompatible-pointer-types
>    F* pf2 = (F*)f;    // -Wcast-function-type
> 
> Likewise by:
> 
>    int f (signed char);
>    typedef int F (unsigned char);
> 
>    F* pf = (F*)f;    // -Wcast-function-type
> 
> I'd expect these conversions to be useful and would view warning
> for them with -Wextra as excessive.  In fact, I'm not sure I see
> the benefit of warning on these casts under any circumstances.
> 

Well, while the first example should be safe,
the second one is probably not safe:

Because the signed and unsigned char are promoted to int,
by the ABI but one is in the range -128..127 while the
other is in the range 0..255, right?


Bernd.

Re: [RFA] [PATCH] Add a warning for invalid function casts

[Martin Sebor]

On 10/05/2017 03:04 PM, Bernd Edlinger wrote:

On 10/05/17 18:16, Martin Sebor wrote:

On 10/03/2017 01:33 PM, Bernd Edlinger wrote:


I'm not sure if this warning may be a bit too strict, but I think
so far it just triggered on rather questionable code.

Thoughts?


My initial thought is that although casts between incompatible
function types undoubtedly mask bugs, the purpose of such casts
is to make such conversions possible.  Indiscriminately diagnosing
them would essentially eliminate this feature of the type system.
Having to add another cast to a different type(*) to suppress
the warning when such a conversion is intended doesn't seem like
a good solution (the next logical step to find bugs in those
conversions would then be to add another warning to see through
those additional casts, and so on).

With that, my question is: under what circumstances does the
warning not trigger on a cast to a function of an incompatible
type?

In my (very quick) tests the warning appears to trigger on all
strictly incompatible conversions, even if they are otherwise
benign, such as:

   int f (const int*);
   typedef int F (int*);

   F* pf1 = f;// -Wincompatible-pointer-types
   F* pf2 = (F*)f;// -Wcast-function-type

Likewise by:

   int f (signed char);
   typedef int F (unsigned char);

   F* pf = (F*)f;// -Wcast-function-type

I'd expect these conversions to be useful and would view warning
for them with -Wextra as excessive.  In fact, I'm not sure I see
the benefit of warning on these casts under any circumstances.

Similarly, for casts between pointers to the same integer type
with a different sign, or those involving ILP32/LP64 portability
issues I'd expect the warning not to trigger unless requested
(e.g., by some other option targeting those issues).

So based on these initial observations and despite the bugs it
may have uncovered, I share your concern that the warning in
its present form is too strict to be suitable for -Wextra, or
possibly even too noisy to be of practical use on its own and
outside of -Wextra.

Out of curiosity, have you done any tests on other code bases
besides GCC to see how many issues (true and false positives)
it finds?

Martin

[*] Strictly speaking, the semantics of casting a function
pointer to intptr_t aren't necessarily well-defined.  Only void*
can be portably converted to intptr_t and back, and only object
pointers are required to be convertible to void* and back.  And
although GCC defines the semantics of these conversions, forcing
programs to abandon a well defined language feature in favor of
one that's not as cleanly specified would undermine the goal
the warning is meant to achieve.


Thanks for your advice.

I did look into openssl and linux, both have plenty of
-Wcast-function-type warnings.

In the case of openssl it is lots of similar stuff
crypto/aes/aes_cfb.c:25:27: warning: cast between incompatible function
types from 'void (*)(const unsigned char *, unsigned char *, const
AES_KEY *) {aka void (*)(const unsigned char *, unsigned char *, const
struct aes_key_st *)}' to 'void (*)(const unsigned char *, unsigned
char *, const void *)' [-Wcast-function-type]
(block128_f) AES_encrypt);

The problem is the function is of course called with a different
signature than what is declared.  They take it somehow for granted,
that "void*" or "const void*" parameter are an alias for
any pointer or any const pointer.  Either as parameter or as return
code.

I would believe this is not well-defined by the c-standard.

But it makes the warning less useful because it would be impossible
to spot the few places where the call will actually abort at
runtime.

Then I tried to compile linux, I noticed that there is a new
warning for the alias to incompatible function.

I saw it very often, and it is always when a system call
is defined:

./include/linux/compat.h:50:18: Warnung: »compat_sys_ptrace« alias
between functions of incompatible types »long int(compat_long_t,
compat_long_t,  compat_long_t,  compat_long_t) {alias long int(int,
int,  int,  int)}« and »long int(long int,  long int,  long int,  long
int)« [-Wattributes]
   asmlinkage long compat_sys##name(__MAP(x,__SC_DECL,__VA_ARGS__))\

./include/linux/syscalls.h:211:18: Warnung: »sys_rt_sigprocmask« alias
between functions of incompatible types »long int(int,  sigset_t *,
sigset_t *, size_t) {alias long int(int,  struct  *, struct
 *, long unsigned int)}« and »long int(long int,  long int,
long int,  long int)« [-Wattributes]
   asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \


Needless to say that even more Wcast-function-type warning
happen.

./include/linux/timer.h:178:23: Warnung: cast between incompatible
function types from »void (*)(struct timer_list *)« to »void (*)(long
unsigned int)« [-Wcast-function-type]
   __setup_timer(timer, (TIMER_FUNC_TYPE)callback,

So they assume obviously that any int / long / pointer value
are compatible with uintptr_t and intptr_t.

Re: [RFA] [PATCH] Add a warning for invalid function casts

[Joseph Myers]

On Thu, 5 Oct 2017, Bernd Edlinger wrote:

> Maybe it would be good to not warn in type-casts, when they can be
> assumed to be safe, for instance
> void* <-> any pointer (parameter or result),
> uintptr_t <-> any int, any pointer (parameter or result),
> void (*) (void) and void (*) (...) <-> any function pointer.

Well, void * and uintptr_t aren't necessarily interchangable at the ABI 
level.  At least, the m68k ABI returns integers in %d0 and pointers in 
%a0; I don't know if any other ABIs have that peculiarity.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [RFA] [PATCH] Add a warning for invalid function casts

[Bernd Edlinger]

On 10/05/17 18:16, Martin Sebor wrote:
> On 10/03/2017 01:33 PM, Bernd Edlinger wrote:
>>
>> I'm not sure if this warning may be a bit too strict, but I think
>> so far it just triggered on rather questionable code.
>>
>> Thoughts?
> 
> My initial thought is that although casts between incompatible
> function types undoubtedly mask bugs, the purpose of such casts
> is to make such conversions possible.  Indiscriminately diagnosing
> them would essentially eliminate this feature of the type system.
> Having to add another cast to a different type(*) to suppress
> the warning when such a conversion is intended doesn't seem like
> a good solution (the next logical step to find bugs in those
> conversions would then be to add another warning to see through
> those additional casts, and so on).
> 
> With that, my question is: under what circumstances does the
> warning not trigger on a cast to a function of an incompatible
> type?
> 
> In my (very quick) tests the warning appears to trigger on all
> strictly incompatible conversions, even if they are otherwise
> benign, such as:
> 
>    int f (const int*);
>    typedef int F (int*);
> 
>    F* pf1 = f;    // -Wincompatible-pointer-types
>    F* pf2 = (F*)f;    // -Wcast-function-type
> 
> Likewise by:
> 
>    int f (signed char);
>    typedef int F (unsigned char);
> 
>    F* pf = (F*)f;    // -Wcast-function-type
> 
> I'd expect these conversions to be useful and would view warning
> for them with -Wextra as excessive.  In fact, I'm not sure I see
> the benefit of warning on these casts under any circumstances.
> 
> Similarly, for casts between pointers to the same integer type
> with a different sign, or those involving ILP32/LP64 portability
> issues I'd expect the warning not to trigger unless requested
> (e.g., by some other option targeting those issues).
> 
> So based on these initial observations and despite the bugs it
> may have uncovered, I share your concern that the warning in
> its present form is too strict to be suitable for -Wextra, or
> possibly even too noisy to be of practical use on its own and
> outside of -Wextra.
> 
> Out of curiosity, have you done any tests on other code bases
> besides GCC to see how many issues (true and false positives)
> it finds?
> 
> Martin
> 
> [*] Strictly speaking, the semantics of casting a function
> pointer to intptr_t aren't necessarily well-defined.  Only void*
> can be portably converted to intptr_t and back, and only object
> pointers are required to be convertible to void* and back.  And
> although GCC defines the semantics of these conversions, forcing
> programs to abandon a well defined language feature in favor of
> one that's not as cleanly specified would undermine the goal
> the warning is meant to achieve.

Thanks for your advice.

I did look into openssl and linux, both have plenty of
-Wcast-function-type warnings.

In the case of openssl it is lots of similar stuff
crypto/aes/aes_cfb.c:25:27: warning: cast between incompatible function 
types from 'void (*)(const unsigned char *, unsigned char *, const
AES_KEY *) {aka void (*)(const unsigned char *, unsigned char *, const 
struct aes_key_st *)}' to 'void (*)(const unsigned char *, unsigned
char *, const void *)' [-Wcast-function-type]
(block128_f) AES_encrypt);

The problem is the function is of course called with a different
signature than what is declared.  They take it somehow for granted,
that "void*" or "const void*" parameter are an alias for
any pointer or any const pointer.  Either as parameter or as return
code.

I would believe this is not well-defined by the c-standard.

But it makes the warning less useful because it would be impossible
to spot the few places where the call will actually abort at
runtime.

Then I tried to compile linux, I noticed that there is a new
warning for the alias to incompatible function.

I saw it very often, and it is always when a system call
is defined:

./include/linux/compat.h:50:18: Warnung: »compat_sys_ptrace« alias 
between functions of incompatible types »long int(compat_long_t, 
compat_long_t,  compat_long_t,  compat_long_t) {alias long int(int, 
int,  int,  int)}« and »long int(long int,  long int,  long int,  long 
int)« [-Wattributes]
   asmlinkage long compat_sys##name(__MAP(x,__SC_DECL,__VA_ARGS__))\

./include/linux/syscalls.h:211:18: Warnung: »sys_rt_sigprocmask« alias 
between functions of incompatible types »long int(int,  sigset_t *, 
sigset_t *, size_t) {alias long int(int,  struct  *, struct 
 *, long unsigned int)}« and »long int(long int,  long int, 
long int,  long int)« [-Wattributes]
   asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \


Needless to say that even more Wcast-function-type warning
happen.

./include/linux/timer.h:178:23: Warnung: cast between incompatible 
function types from »void (*)(struct timer_list *)« to »void (*)(long 
unsigned int)« [-Wcast-function-type]
   __setup_timer(timer, (TIMER_FUNC_TYPE)callback,

So they 

Re: [RFA] [PATCH] Add a warning for invalid function casts

[Eric Gallager]

On 10/5/17, Bernd Edlinger  wrote:
> On 10/05/17 02:24, Eric Gallager wrote:
>> Sorry if this is a stupid question, but could you explain how this
>> warning is different from -Wbad-function-cast? Something about direct
>> calls to functions vs. passing them as function pointers?
>
> No, it is not :)
>
> -Wbad-function-cast is IMHO a strange legacy warning.
>
> It is C-only, and it triggers only if the result of a function call
> is cast to a type with a different TREE_CODE, so for instance
> int <-> float <-> pointer.
>
> It would trigger for perfectly valid code like this:
>
> i = (int) floor (f);
>
> while we have no warning for
>
> i = floor (f);
>
> What I want to diagnose is assigning a function pointer via an explicit
> type cast to another function pointer, when there is no possible
> implicit conversion between the two function pointer types.
> Thus the cast was used to silence a warning/error in the first place.

OK, thanks for explaining! I kinda worry about warning on code that
was added to silence other warnings in the first place, as it can lead
to frustration when making a fix expecting the number of warnings when
compiling to decrease, but then they don't actually decrease. But as
long as there's a simple way to fix the warned-on code that silences
both the original warning being avoided, and this new one, I see how
it'll be useful.

>
> The idea for this warning came up when someone spotted a place in
> openssl, where a type cast was used to change the return value of a
> callback function from long to int:
>
> https://github.com/openssl/openssl/issues/4413
>
> But due to the type cast there was never ever any warning from this
> invalid type cast.
>
>
> Bernd.
>

Thanks for working on this!

Eric

Re: [RFA] [PATCH] Add a warning for invalid function casts

[Martin Sebor]

On 10/03/2017 01:33 PM, Bernd Edlinger wrote:

Hi!

I have implemented a warning -Wcast-function-type that analyzes
type casts which change the function signatures.

I would consider function pointers with different result type
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
used for instance in recog.h, the warning allows casting
a function with the type typedef rtx (*stored_funcptr) (...);
to any function with the same result type.

I would think a warning like that should be enabled with -Wextra.

Attached is a first version of the patch and as you can see
the warning found already lots of suspicious type casts.  The worst
is the splay-tree which always calls functions with uintptr_t
instead of the correct parameter type.  I was unable to find
a solution for this, and just silenced the warning with a
second type-cast.

Note that I also changed one line in libgo, but that is only
a quick hack which I only did to make the boot-strap with
all languages succeed.

I'm not sure if this warning may be a bit too strict, but I think
so far it just triggered on rather questionable code.

Thoughts?


My initial thought is that although casts between incompatible
function types undoubtedly mask bugs, the purpose of such casts
is to make such conversions possible.  Indiscriminately diagnosing
them would essentially eliminate this feature of the type system.
Having to add another cast to a different type(*) to suppress
the warning when such a conversion is intended doesn't seem like
a good solution (the next logical step to find bugs in those
conversions would then be to add another warning to see through
those additional casts, and so on).

With that, my question is: under what circumstances does the
warning not trigger on a cast to a function of an incompatible
type?

In my (very quick) tests the warning appears to trigger on all
strictly incompatible conversions, even if they are otherwise
benign, such as:

  int f (const int*);
  typedef int F (int*);

  F* pf1 = f;// -Wincompatible-pointer-types
  F* pf2 = (F*)f;// -Wcast-function-type

Likewise by:

  int f (signed char);
  typedef int F (unsigned char);

  F* pf = (F*)f;// -Wcast-function-type

I'd expect these conversions to be useful and would view warning
for them with -Wextra as excessive.  In fact, I'm not sure I see
the benefit of warning on these casts under any circumstances.

Similarly, for casts between pointers to the same integer type
with a different sign, or those involving ILP32/LP64 portability
issues I'd expect the warning not to trigger unless requested
(e.g., by some other option targeting those issues).

So based on these initial observations and despite the bugs it
may have uncovered, I share your concern that the warning in
its present form is too strict to be suitable for -Wextra, or
possibly even too noisy to be of practical use on its own and
outside of -Wextra.

Out of curiosity, have you done any tests on other code bases
besides GCC to see how many issues (true and false positives)
it finds?

Martin

[*] Strictly speaking, the semantics of casting a function
pointer to intptr_t aren't necessarily well-defined.  Only void*
can be portably converted to intptr_t and back, and only object
pointers are required to be convertible to void* and back.  And
although GCC defines the semantics of these conversions, forcing
programs to abandon a well defined language feature in favor of
one that's not as cleanly specified would undermine the goal
the warning is meant to achieve.

Re: [RFA] [PATCH] Add a warning for invalid function casts

[Joseph Myers]

On Thu, 5 Oct 2017, Bernd Edlinger wrote:

> But why is int(*)(int) compatible to (int)(*)() but not
> to int(*)(int,...) ?

I think it's a matter of what function types were possible in K C.  
 variadic types weren't (there was an older ), and 
neither were types with arguments of type float or narrower-than-int 
integers (because those always got promoted to a wider type when passed as 
function arguments to an unprototyped function).  And those types that 
were impossible in K C always require function prototypes.  (The 
possibility of function types without a prototype is a legacy feature.  
There was some suggestion of removing it for C11, but no-one ever produced 
a paper for WG14 proposing the actual wording changes that would have been 
needed.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [RFA] [PATCH] Add a warning for invalid function casts

[Andreas Schwab]

On Okt 05 2017, Bernd Edlinger  wrote:

> The idea for this warning came up when someone spotted a place in
> openssl, where a type cast was used to change the return value of a
> callback function from long to int:
>
> https://github.com/openssl/openssl/issues/4413
>
> But due to the type cast there was never ever any warning from this
> invalid type cast.

Note that the type cast itself is perfectly valid (all function pointers
are alike), but it's the call site that is problematic: unless it casts
back to the real type of the function before the call it is causing
undefined behviour.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [RFA] [PATCH] Add a warning for invalid function casts

[Bernd Edlinger]

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.

Re: [RFA] [PATCH] Add a warning for invalid function casts

[Bernd Edlinger]

On 10/05/17 02:24, Eric Gallager wrote:
> Sorry if this is a stupid question, but could you explain how this
> warning is different from -Wbad-function-cast? Something about direct
> calls to functions vs. passing them as function pointers?

No, it is not :)

-Wbad-function-cast is IMHO a strange legacy warning.

It is C-only, and it triggers only if the result of a function call
is cast to a type with a different TREE_CODE, so for instance
int <-> float <-> pointer.

It would trigger for perfectly valid code like this:

i = (int) floor (f);

while we have no warning for

i = floor (f);

What I want to diagnose is assigning a function pointer via an explicit
type cast to another function pointer, when there is no possible
implicit conversion between the two function pointer types.
Thus the cast was used to silence a warning/error in the first place.

The idea for this warning came up when someone spotted a place in
openssl, where a type cast was used to change the return value of a
callback function from long to int:

https://github.com/openssl/openssl/issues/4413

But due to the type cast there was never ever any warning from this
invalid type cast.


Bernd.

Re: [RFA] [PATCH] Add a warning for invalid function casts

[Eric Gallager]

On Tue, Oct 3, 2017 at 3:33 PM, Bernd Edlinger
 wrote:
> Hi!
>
> I have implemented a warning -Wcast-function-type that analyzes
> type casts which change the function signatures.
>
> I would consider function pointers with different result type
> 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
> used for instance in recog.h, the warning allows casting
> a function with the type typedef rtx (*stored_funcptr) (...);
> to any function with the same result type.
>
> I would think a warning like that should be enabled with -Wextra.
>
> Attached is a first version of the patch and as you can see
> the warning found already lots of suspicious type casts.  The worst
> is the splay-tree which always calls functions with uintptr_t
> instead of the correct parameter type.  I was unable to find
> a solution for this, and just silenced the warning with a
> second type-cast.
>
> Note that I also changed one line in libgo, but that is only
> a quick hack which I only did to make the boot-strap with
> all languages succeed.
>
> I'm not sure if this warning may be a bit too strict, but I think
> so far it just triggered on rather questionable code.
>
> Thoughts?
>
>
> Bernd.

Sorry if this is a stupid question, but could you explain how this
warning is different from -Wbad-function-cast? Something about direct
calls to functions vs. passing them as function pointers?

Re: [RFA] [PATCH] Add a warning for invalid function casts

[Joseph Myers]

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.

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.

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.

-- 
Joseph S. Myers
jos...@codesourcery.com

[RFA] [PATCH] Add a warning for invalid function casts

[Bernd Edlinger]

Hi!

I have implemented a warning -Wcast-function-type that analyzes
type casts which change the function signatures.

I would consider function pointers with different result type
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
used for instance in recog.h, the warning allows casting
a function with the type typedef rtx (*stored_funcptr) (...);
to any function with the same result type.

I would think a warning like that should be enabled with -Wextra.

Attached is a first version of the patch and as you can see
the warning found already lots of suspicious type casts.  The worst
is the splay-tree which always calls functions with uintptr_t
instead of the correct parameter type.  I was unable to find
a solution for this, and just silenced the warning with a
second type-cast.

Note that I also changed one line in libgo, but that is only
a quick hack which I only did to make the boot-strap with
all languages succeed.

I'm not sure if this warning may be a bit too strict, but I think
so far it just triggered on rather questionable code.

Thoughts?


Bernd.
gcc:
2017-10-03  Bernd Edlinger  

* doc/invoke.texi: Document -Wcast-function-type.
* gengtype.c (write_root): Remove cast.
* ggc.h (gt_pch_n_S_nonconst, gt_ggc_m_S_nonconst): Declare.
* ggc-page.c (gt_ggc_m_S_nonconst): New function.
* stringpool.c (gt_pch_n_S_nonconst): New function.
* tree-pass.h (do_per_function_toporder): Adjust header.
* passes.c (do_per_function_toporder): Change signature.
(execute_ipa_pass_list): Remove cast.
* recog.h (f0..f15): Fix return types.
(stored_funcptr): Use variadic parameter list.
* tree-dump.c (dump_node): Avoid warning.
* typed-splay-tree.h (typed_splay_tree): Avoid warning.

libcpp:
2017-10-03  Bernd Edlinger  

* include/symtab.h (ht_forall_internal): Declare.
* symtab.c (ht_forall_internal): New function.
* internal.h (maybe_print_line): Change signature.

c-family:
2017-10-03  Bernd Edlinger  

* c.opt (Wcast-function-type): New warning option.
* c-lex.c (get_fileinfo): Avoid warning.
* c-ppoutput.c (scan_translation_unit_directives_only): Remove cast.

c:
2017-10-03  Bernd Edlinger  

* c-typeck.c (build_c_cast): Implement -Wcast_function_type.

cp:
2017-10-03  Bernd Edlinger  

* cxx-pretty-print.c (pp_c_type_specifier_seq,
pp_c_parameter_declaration_clause): New wrapper functions.
(cxx_pretty_printer::cxx_pretty_printer): Remove cast.
* decl2.c (start_static_storage_duration_function): Aboid warning.
* typeck.c (build_reinterpret_cast_1): Implement -Wcast_function_type.

testsuite:
2017-10-03  Bernd Edlinger  

* c-c++-common/Wcast-function-type.c: New test.
Index: gcc/c/c-typeck.c
===
--- gcc/c/c-typeck.c	(revision 253328)
+++ gcc/c/c-typeck.c	(working copy)
@@ -5667,6 +5667,20 @@ build_c_cast (location_t loc, tree type, tree expr
 	pedwarn (loc, OPT_Wpedantic, "ISO C forbids "
 		 "conversion of object pointer to function pointer type");
 
+  if (TREE_CODE (type) == POINTER_TYPE
+	  && TREE_CODE (otype) == POINTER_TYPE
+	  && TREE_CODE (TREE_TYPE (type)) == FUNCTION_TYPE
+	  && TREE_CODE (TREE_TYPE (otype)) == FUNCTION_TYPE
+	  && (TYPE_ARG_TYPES (TREE_TYPE (type))
+	  && TYPE_ARG_TYPES (TREE_TYPE (otype))
+	  ? !comptypes (TREE_TYPE (type),
+			TREE_TYPE (otype))
+	  : !comptypes (TREE_TYPE (TREE_TYPE (type)),
+			TREE_TYPE (TREE_TYPE (otype)
+	warning_at (loc, OPT_Wcast_function_type,
+		"cast between incompatible function types"
+		" from %qT to %qT", otype, type);
+
   ovalue = value;
   value = convert (type, value);
 
Index: gcc/c-family/c-lex.c
===
--- gcc/c-family/c-lex.c	(revision 253328)
+++ gcc/c-family/c-lex.c	(working copy)
@@ -101,9 +101,11 @@ get_fileinfo (const char *name)
   struct c_fileinfo *fi;
 
   if (!file_info_tree)
-file_info_tree = splay_tree_new ((splay_tree_compare_fn) strcmp,
+file_info_tree = splay_tree_new ((splay_tree_compare_fn)
+ (uintptr_t) strcmp,
  0,
- (splay_tree_delete_value_fn) free);
+ (splay_tree_delete_value_fn)
+ (uintptr_t) free);
 
   n = splay_tree_lookup (file_info_tree, (splay_tree_key) name);
   if (n)
Index: gcc/c-family/c-ppoutput.c
===
--- gcc/c-family/c-ppoutput.c	(revision 253328)
+++ gcc/c-family/c-ppoutput.c	(working copy)
@@ -299,7 +299,7 @@ scan_translation_unit_directives_only (cpp_reader
   struct _cpp_dir_only_callbacks cb;