Re: Clang UndefinedBehaviorSanitize (Postgres14) Detected undefined-behavior - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Clang UndefinedBehaviorSanitize (Postgres14) Detected undefined-behavior
Date
Msg-id 840693.1599188017@sss.pgh.pa.us
Whole thread Raw
In response to Re: Clang UndefinedBehaviorSanitize (Postgres14) Detected undefined-behavior  (Noah Misch <noah@leadboat.com>)
Responses Re: Clang UndefinedBehaviorSanitize (Postgres14) Detected undefined-behavior  (Peter Geoghegan <pg@bowt.ie>)
Re: Clang UndefinedBehaviorSanitize (Postgres14) Detected undefined-behavior  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
Noah Misch <noah@leadboat.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



pgsql-hackers by date:

Previous
From: "tsunakawa.takay@fujitsu.com"
Date:
Subject: RE: New statistics for tuning WAL buffer size
Next
From: Amit Langote
Date:
Subject: Re: default partition and concurrent attach partition