From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, 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-08-29 16:36:42 |
Message-ID: | 3564829.1598719002@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Geoghegan <pg(at)bowt(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-08-29 16:50:59 | Re: Ideas about a better API for postgres_fdw remote estimates |
Previous Message | Stephen Frost | 2020-08-29 16:22:31 | Re: Ideas about a better API for postgres_fdw remote estimates |