[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Fix implicit-signed-integer-truncation in hash function
From: |
Jose E. Marchesi |
Subject: |
Re: [PATCH] Fix implicit-signed-integer-truncation in hash function |
Date: |
Mon, 18 May 2020 10:18:10 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
> The ASAN report was:
> pkl-env.c:74:12: runtime error: implicit conversion from type
'unsigned long'
> of value 591105371825 (64-bit, unsigned) to type 'int' changed the
value to
> -1600115023 (32-bit, signed)
>
> 2020-05-17 Tim Rühsen <address@hidden>
>
> * libpoke/pkl-env.c (hash_string): Suppress ASAN runtime error
> "implicit-signed-integer-truncation-or-sign-change".
> ---
> ChangeLog | 5 +++++
> libpoke/pkl-env.c | 4 +++-
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/libpoke/pkl-env.c b/libpoke/pkl-env.c
> index e1a74d42..636d0a84 100644
> --- a/libpoke/pkl-env.c
> +++ b/libpoke/pkl-env.c
> @@ -60,7 +60,9 @@ struct pkl_env
>
> /* The hash tables above are handled using the following
> functions. */
> -
> +#ifdef __clang__
> +__attribute__((no_sanitize("integer")))
> +#endif
> static int
> hash_string (const char *name)
> {
>
> Hm is the sanitizer not reporting the error in GCC?
No, not for gcc-9.
gcc (at least gcc-9) doesn't have an "integer" check mode, which groups
several integer-related tests.
In the past, new sanitizer options were introduced in llvm/clang first,
then slowly picked up by gcc. So my hope is, gcc picks up "integer" mode
at some day.
Yes, GCC updates its port of the sanitizers from time to time.
From my experience, testing ASAN and UBSAN with clang finds way more
issues than gcc does.
In this special case, I prefer an attribute in the code. Because the
hash functions often rely on integer overflow (and other integer stuff
that might trigger a sanitizer).
To handle false positives or otherwise unfixable code, I prefer a
suppression file.
OK for master then.
Thanks!