Re: Clang UndefinedBehaviorSanitize (Postgres14) Detected undefined-behavior

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Peter Geoghegan <pg(at)bowt(dot)ie>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Clang UndefinedBehaviorSanitize (Postgres14) Detected undefined-behavior
Date: 2020-09-04 02:53:37
Message-ID: 840693.1599188017@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Noah Misch <noah(at)leadboat(dot)com> writes:
> We do assume dereferencing NULL would crash, but we also assume this
> optimization doesn't happen:

> #ifndef REMOVE_MEMCPY
> memcpy(dest, src, n);
> #endif
> if (src)
> pause();

> [ gcc believes the if-test is unnecessary ]

Hm. I would not blame that on -fdelete-null-pointer-checks per se.
Rather the problem is what we were touching on before: the dubious
but standard-approved assumption that memcpy's arguments cannot be
null.

If there actually are places where this is a problem, I think we
need to fix it by doing

if (n > 0)
memcpy(dest, src, n);

so that the compiler can no longer assume that src!=NULL even
when n is zero. I'd still leave -fdelete-null-pointer-checks
enabled, because it can make valid and useful optimizations in
other cases. (Besides that, it's far from clear that disabling
that flag would suppress all bad consequences of the assumption
that memcpy's arguments aren't null.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2020-09-04 02:57:33 Re: default partition and concurrent attach partition
Previous Message tsunakawa.takay@fujitsu.com 2020-09-04 02:50:10 RE: New statistics for tuning WAL buffer size