Re: [lmi] [lmi-commits] master 3a5c416d 5/6: Reenable a warning and resolve its cause

[Greg Chicares]

On 6/29/22 15:31, Vadim Zeitlin wrote:
> On Wed, 29 Jun 2022 11:11:35 -0400 (EDT) Greg Chicares 
> <gchicares@sbcglobal.net> wrote:
[...]
> GC>     In cases like this:
> GC>       location_info(line_num, current - start + 1)
> GC>     the second argument is a pointer difference, but its type was 'int'.
> GC>     Changing the type to 'long int' would work for LP64, but 'long long 
> int'
> GC>     is needed for LLP64.
> 
>  Unfortunately the original history was lost, so I don't know if I gave any
> rationale for using int here in the commit message adding it, but right now
> I can't think of any reason for not using ptrdiff_t here. Shouldn't we just
> do this, instead?

I thought of using ptrdiff_t here, but lmi doesn't use that type
anywhere; and, having spent considerable effort getting rid of most
uses of std::size_t, I hesitate to let std::ptrdiff_t leak in.

It's merely silly for std::size_t to be unsigned in modern times,
whereas std::ptrdiff_t is entirely misconceived. To represent the
difference between any two 64-bit addresses requires one sign bit
plus a sixty-four-bit significand: given that C++ allows only
two's complement, a sixty-five bit integer is necessary. (Cf.
C99 [7.18.3/2], which says (PTRDIFF_MIN, PTRDIFF_MAX) must be
at least (-65535, +65535), which requires a seventeen-bit type.)
Because that logical requirement is impractical, they just punt
and say that if it doesn't fit in the valid range of intmax_t,
then that constitutes undefined behavior. It's broken by design.

(I won't even mention that contemporary x86_64 CPUs only allow
48-bit addresses anyway.)

>  BTW, there are also a number of bourn_cast<>s that should have become
> unnecessary now (and would also be unnecessary if we used ptrdiff_t).

I view it in the opposite way: all those bourn_cast<>s are good,
and the real problem is that there aren't enough of them.

If we blithely widen all the types, then we allow pointer
differences of nine quintillion bytes. Using bourn_cast
gives us an error message if that happens. I'll push a change
with that improvement.