[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 1/4] localename: -Wtautological-pointer-compare
From: |
Bruno Haible |
Subject: |
Re: [PATCH 1/4] localename: -Wtautological-pointer-compare |
Date: |
Sun, 15 Jan 2023 23:03:09 +0100 |
Hi Paul,
> My confusion arose partly because I am accustomed to languages where the
> distinction between null and non-null pointers is checked statically and
> reliably, and I keep forgetting that with C, GCC and Clang are only poor
> approximations to that
Oh, now I understand. May I guess the language: Haskell, OCaml, TypeScript,
Rust?
> - though I hope the approximations are slowly getting better.
Still it will take a lot of time. The following steps need to happen:
1. Standards need to define a notation for declaring a non-null type value,
non-null argument, or non-null return value. (Partially done.)
2. Compilers need to diagnose places where a non-null declaration could be
added, like they do for function attributes __pure__ and __const__.
3. Developers need to add such declarations to their .h files.
Then only such static checking can happen, without producing floods of
diagnostics that developers would discard.
> Also, in my experience the debugger doesn't always point to the exact
> line of the abort(). For example, if there are two abort() calls in the
> same function they are routinely coalesced.
True :( I should have mentioned to compile with "-g -O0", not just "-g".
> To give a different example: I wouldn't bother with the following code
> (where M and N are int arguments to a function):
>
> if (n == 0)
> abort ();
> if (n == -1 && m < -INT_MAX)
> abort ();
> return m / n;
>
> and would instead write this:
>
> return m / n;
>
> as the user and debugging experiences are similar and the shorter form
> simplifies code maintenance.
Unfortunately, this is an excellent example for a portability problem:
The division yields a SIGFPE on x86, x86_64, alpha, m68k, and s390/s390x
CPU, but not on other architectures.
> Sure, the longer form is safer for oddball
> platforms, but it's not worth the aggravation.
Some distros feel differently. I have such code in GNU gettext, and
optimize away the entry checks on platforms where I know it yields a SIGFPE.
And some distros disabled these optimizations, i.e. enabled the entry checks
always...
Bruno