On 2022-03-26 11:08:59 -0700, Andres Freund wrote:
> On 2022-03-26 10:49:53 -0700, Andres Freund wrote:
> > > It's hard to see how that isn't a flat-out compiler bug.
> >
> > It only happens if the NULL is directly passed as an argument to the macro,
> > not if there's an intermediary variable. Arg
Andres Freund writes:
> Looks good wrt relptr_store. Maybe we should fix the double-eval hazard in
> relptr_access too, think that'd be only one left over...
Hm. Probably not worth the trouble, because it's hard to envision
a situation where rp is not a plain lvalue.
reg
Hi,
On 2022-03-26 14:13:56 -0400, Tom Lane wrote:
> The attached also silences the warning, and getting rid of the double-eval
> hazard seems like a net win.
Looks good wrt relptr_store. Maybe we should fix the double-eval hazard in
relptr_access too, think that'd be only one left over...
> > M
Andres Freund writes:
> Wonder if we should try to get rid of the problem by also fixing the double
> evaluation of val? I think something like
Good idea. The attached also silences the warning, and getting rid
of the double-eval hazard seems like a net win.
> Might also be worth adding an asse
Hi,
On 2022-03-26 10:49:53 -0700, Andres Freund wrote:
> > It's hard to see how that isn't a flat-out compiler bug.
>
> It only happens if the NULL is directly passed as an argument to the macro,
> not if there's an intermediary variable. Argh.
>
>
> #include
>
> #define relptr_store(base, rp
I wrote:
> clang is complaining about the subtraction despite it being inside
> a conditional arm that cannot be reached when val is null. It's hard
> to see how that isn't a flat-out compiler bug.
> However, granting that it isn't going to get fixed right away,
> we could replace these call sites
relptr value to "null" (zero),
> and AFAICS it should be allowed:
>
> freepage.c:188:2: warning: performing pointer subtraction with a null pointer
> has undefined behavior [-Wnull-pointer-subtraction]
> relptr_store(base, fpm->btree_root, (FreePageBtree *) NULL);
&
It's a warning present in 13, but not in 12.
> OK, that answers that.
... Actually, after looking closer, I misread what our code is doing.
These call sites are trying to set the relptr value to "null" (zero),
and AFAICS it should be allowed:
freepage.c:188:2: warning: performing po
Andres Freund writes:
> On 2022-03-26 12:13:12 -0400, Tom Lane wrote:
>> This code is old, but mylodon wasn't doing that a week ago, so
>> Andres must've updated the compiler and/or changed its options.
> Yep, updated it to clang 13. It's a warning present in 13, but not in 12.
OK, that answers
Hi,
On 2022-03-26 12:13:12 -0400, Tom Lane wrote:
> This code is old, but mylodon wasn't doing that a week ago, so
> Andres must've updated the compiler and/or changed its options.
Yep, updated it to clang 13. It's a warning present in 13, but not in 12.
I'll update it to 14 soon, now that that'
On Sat, 26 Mar 2022 at 12:24, Andres Freund wrote:
> NULL can never be part of the same "array object" or one past past the last
> element as the pointer it is subtracted from. Hence the undefined beaviour.
>
Even more fundamentally, NULL is not 0 in any ordinary mathematical sense,
even though
Hi,
On 2022-03-26 12:04:54 -0400, Tom Lane wrote:
> Several of Andres' buildfarm animals have recently started to whine
> that "performing pointer subtraction with a null pointer has undefined
> behavior" for assorted places in freepage.c.
>
> From a mathematical
I wrote:
> Several of Andres' buildfarm animals have recently started to whine
> that "performing pointer subtraction with a null pointer has undefined
> behavior" for assorted places in freepage.c.
Ah, sorry, I meant to include a link:
https://buildfarm.postgresql.org/c
Several of Andres' buildfarm animals have recently started to whine
that "performing pointer subtraction with a null pointer has undefined
behavior" for assorted places in freepage.c.
>From a mathematical standpoint, this astonishes me: "x - 0 = x" is a
tautology.
14 matches
Mail list logo
