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 (I
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 A
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 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
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, M
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 w
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* witho
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 calle
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 = "
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
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 mode
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 v
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.
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
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? T
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
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,
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
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 inst
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
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 heu
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, eve
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 a
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-c
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 o
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:
>>>
>>>
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 re
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
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
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;
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-type
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 alt
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
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
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
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
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&R C.
variadic types weren't (there was an older ), and
neither were types with arguments of type float or
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 the
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
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 l
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-nul
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
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 except
43 matches
Mail list logo
