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

[Vadim Zeitlin]

On Wed, 29 Jun 2022 21:16:28 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> On 6/29/22 15:31, Vadim Zeitlin wrote:
GC> [...]
GC> >  BTW, there are also a number of bourn_cast<>s that should have become
GC> > unnecessary now (and would also be unnecessary if we used ptrdiff_t).
GC> 
GC> I view it in the opposite way: all those bourn_cast<>s are good,
GC> and the real problem is that there aren't enough of them.
GC> 
GC> If we blithely widen all the types, then we allow pointer
GC> differences of nine quintillion bytes. Using bourn_cast
GC> gives us an error message if that happens. I'll push a change
GC> with that improvement.

 FWIW I agree that it's an improvement, i.e. if we do not use ptrdiff_t,
then we should indeed use explicit casts everywhere, but it seems a bit
weird to me to have 2 overloaded ctors now and I wonder if it can't result
in ambiguities when choosing the appropriate overload.

 I.e. I'd rather have a single ctor and only keep the cast inside it, maybe
using an explicit check to allow giving a more clear message (e.g.
"unexpectedly huge rate table file") than what bourn_cast<> would give.

 But mostly having both ctors _and_ casts in some, but not all places seems
too inconsistent to be a good idea to me.

VZ

pgpOXGJFTdKRa.pgp
Description: PGP signature