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 3564829.1598719002@sss.pgh.pa.us
Whole thread Raw
In response to Re: Clang UndefinedBehaviorSanitize (Postgres14) Detected undefined-behavior  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: Clang UndefinedBehaviorSanitize (Postgres14) Detected undefined-behavior
Re: Clang UndefinedBehaviorSanitize (Postgres14) Detected undefined-behavior
List pgsql-hackers
Peter Geoghegan <pg@bowt.ie> writes:
> I wonder if we should start using -fno-delete-null-pointer-checks:
> https://lkml.org/lkml/2018/4/4/601
> This may not be strictly relevant to the discussion, but I was
> reminded of it just now and thought I'd mention it.

Hmm.  gcc 8.3 defines this as:

     Assume that programs cannot safely dereference null pointers, and
     that no code or data element resides at address zero.  This option
     enables simple constant folding optimizations at all optimization
     levels.  In addition, other optimization passes in GCC use this
     flag to control global dataflow analyses that eliminate useless
     checks for null pointers; these assume that a memory access to
     address zero always results in a trap, so that if a pointer is
     checked after it has already been dereferenced, it cannot be null.

AFAICS, that's a perfectly valid assumption for our usage.  I can see why
the kernel might not want it, but we set things up whenever possible to
ensure that dereferencing NULL would crash.

However, while grepping the manual for that I also found

'-Wnull-dereference'
     Warn if the compiler detects paths that trigger erroneous or
     undefined behavior due to dereferencing a null pointer.  This
     option is only active when '-fdelete-null-pointer-checks' is
     active, which is enabled by optimizations in most targets.  The
     precision of the warnings depends on the optimization options used.

I wonder whether turning that on would find anything interesting.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: More aggressive vacuuming of temporary tables
Next
From: Tom Lane
Date:
Subject: Re: Ideas about a better API for postgres_fdw remote estimates