On 2020-07-07 18:08, Tom Lane wrote:
Peter Eisentraut writes:
On 2020-07-04 16:16, Tom Lane wrote:
I'm for a typedef. There is *nothing* readable about "(void (*) (void))",
and the fact that it's theoretically incorrect for the purpose doesn't
exactly aid intelligibility either. With a
Peter Eisentraut writes:
> On 2020-07-04 16:16, Tom Lane wrote:
>> I'm for a typedef. There is *nothing* readable about "(void (*) (void))",
>> and the fact that it's theoretically incorrect for the purpose doesn't
>> exactly aid intelligibility either. With a typedef, not only are
>> the uses
On 2020-07-04 16:16, Tom Lane wrote:
Peter Eisentraut writes:
Do people prefer a typedef or just writing it out, like it's done in the
Python code?
I'm for a typedef. There is *nothing* readable about "(void (*) (void))",
and the fact that it's theoretically incorrect for the purpose
Peter Eisentraut writes:
> Do people prefer a typedef or just writing it out, like it's done in the
> Python code?
I'm for a typedef. There is *nothing* readable about "(void (*) (void))",
and the fact that it's theoretically incorrect for the purpose doesn't
exactly aid intelligibility
On 2020-07-03 16:40, Tom Lane wrote:
Given that gcc explicitly documents "void (*) (void)" as being what
to use, they're going to have a hard time changing their minds about
that ... and gcc is dominant enough in this space that I suppose
other compilers would have to be compatible with it. So
Peter Eisentraut writes:
> On 2020-06-30 21:38, Tom Lane wrote:
>> In any case, I think the issue here is what is the escape hatch for saying
>> that "I know this cast is okay, don't warn about it, thanks". Treating
>> "void (*) (void)" as special for that purpose is nothing more nor less
>>
On 2020-06-30 21:38, Tom Lane wrote:
In any case, I think the issue here is what is the escape hatch for saying
that "I know this cast is okay, don't warn about it, thanks". Treating
"void (*) (void)" as special for that purpose is nothing more nor less
than a kluge, so another compiler might
Andres Freund writes:
> On 2020-06-30 10:15:05 -0400, Tom Lane wrote:
>> I feel like what you propose to do here is just shifting the problem
>> around: we're still casting from a function pointer that describes one
>> concrete call ABI to a function pointer that describes some other concrete
>>
Hi,
On 2020-06-30 10:15:05 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > There are three subplots:
>
> > 1. Changing the return type of load_external_function() and
> > lookup_external_function() from PGFunction to a generic pointer type,
> > which is what the discussion in [0]
Hi,
On 2020-06-30 08:47:56 +0200, Peter Eisentraut wrote:
> Some time ago, there were some discussions about gcc warnings produced by
> -Wcast-function-type [0]. To clarify, while that thread seemed to imply
> that the warnings appear by default in some compiler version, this is not
> the case
Peter Eisentraut writes:
> There are three subplots:
> 1. Changing the return type of load_external_function() and
> lookup_external_function() from PGFunction to a generic pointer type,
> which is what the discussion in [0] started out about.
I feel like what you propose to do here is just
Some time ago, there were some discussions about gcc warnings produced
by -Wcast-function-type [0]. To clarify, while that thread seemed to
imply that the warnings appear by default in some compiler version, this
is not the case AFAICT, and the warnings are entirely optional.
So I took a
12 matches
Mail list logo
