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
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
19 matches
Mail list logo
