[Top][All Lists]

[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,

> - 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]