diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2022-03-03 18:13:24 -0500 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2022-03-03 18:13:24 -0500 |
| commit | 1a027e6b7bdf06dc3bfe1e63a2493f13629cf44a (patch) | |
| tree | a930f1dd82cab9edee068a3079691eb158d6cff6 /src/backend/utils/adt/numeric.c | |
| parent | 6599d8f1264299ee595f2eaf4dc6a9aa2d7940d2 (diff) | |
| download | postgresql-1a027e6b7bdf06dc3bfe1e63a2493f13629cf44a.tar.gz postgresql-1a027e6b7bdf06dc3bfe1e63a2493f13629cf44a.zip | |
Clean up assorted failures under clang's -fsanitize=undefined checks.
Most of these are cases where we could call memcpy() or other libc
functions with a NULL pointer and a zero count, which is forbidden
by POSIX even though every production version of libc allows it.
We've fixed such things before in a piecemeal way, but apparently
never made an effort to try to get them all. I don't claim that
this patch does so either, but it gets every failure I observe in
check-world, using clang 12.0.1 on current RHEL8.
numeric.c has a different issue that the sanitizer doesn't like:
"ln(-1.0)" will compute log10(0) and then try to assign the
resulting -Inf to an integer variable. We don't actually use the
result in such a case, so there's no live bug.
Back-patch to all supported branches, with the idea that we might
start running a buildfarm member that tests this case. This includes
back-patching c1132aae3 (Check the size in COPY_POINTER_FIELD),
which previously silenced some of these issues in copyfuncs.c.
Discussion: https://postgr.es/m/CALNJ-vT9r0DSsAOw9OXVJFxLENoVS_68kJ5x0p44atoYH+H4dg@mail.gmail.com
Diffstat (limited to 'src/backend/utils/adt/numeric.c')
| -rw-r--r-- | src/backend/utils/adt/numeric.c | 8 |
1 files changed, 8 insertions, 0 deletions
diff --git a/src/backend/utils/adt/numeric.c b/src/backend/utils/adt/numeric.c index 885d50f5fc3..041d0dbc1d6 100644 --- a/src/backend/utils/adt/numeric.c +++ b/src/backend/utils/adt/numeric.c @@ -8886,12 +8886,20 @@ exp_var(const NumericVar *arg, NumericVar *result, int rscale) * * Essentially, we're approximating log10(abs(ln(var))). This is used to * determine the appropriate rscale when computing natural logarithms. + * + * Note: many callers call this before range-checking the input. Therefore, + * we must be robust against values that are invalid to apply ln() to. + * We don't wish to throw an error here, so just return zero in such cases. */ static int estimate_ln_dweight(const NumericVar *var) { int ln_dweight; + /* Caller should fail on ln(negative), but for the moment return zero */ + if (var->sign != NUMERIC_POS) + return 0; + if (cmp_var(var, &const_zero_point_nine) >= 0 && cmp_var(var, &const_one_point_one) <= 0) { |