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
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 |