Re: [boost] [serialization][1_42_0] basic_binary_oarchive - warning: comparison is always true due to limited range of data type

Subject: Re: [boost] [serialization][1_42_0] basic_binary_oarchive - warning: comparison is always true due to limited range of data type
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-04-09 13:26:20

> Note that I ran into this same warning recently as part of upgrading
> to boost 1.42. Some research led me to write the following comment in
> my local patch:
>
>    // kab, 4/2/2010: workaround for gcc warnings:
>    //   comparison is always true due to limited range of data type
>    // gcc 4.3 and later provide warning controls for this: controled
>    by // -W[no-]type-limits, defaulting to disabled and enabled by
>    -Wextra. // gcc versions prior to that provide NO CONTROL over
>    this warning, which // first appeared circa gcc 3.3.2. see gcc bug
> 12963.
>
> Frankly I'm hard-pressed to ever think of a situation where I'd want
> to enable this warning, but unfortunately there's no way to disable it
> for a significant range of gcc versions.
>
> For expedience I changed these asserts to use boost.numeric.conversion
> facilities to perform the range check, as it carefully optimizes out
> tests guaranteed to succeed, and so avoids triggering the warning in
> question. I'm guessing that a real patch that Robert would accept
> would avoid adding the dependency on boost.numeric.conversion, but
> that was good enough for my immediate purposes. Specifically, my patch
> introduces the following helper function:
>
>  template<class T, class S>
>  bool save_override_check(S s) {
>      return boost::numeric::cInRange
>             == boost::numeric::converter<T, S>::out_of_range(s);
>  }
>
> which is used as
>
>  assert(save_override_check<boost::int_least16_t>(t.t));

Well, this discussion makes me want to re-consider - at my leasure -
what kind of checking - if any - should be done.  It touches upon
other issues as well, such as my imposed requirement that all
archives should act identical.  Feel free to open a track item on
this so that it will hang around forever or until it's specifically
considerd - whichever comes first.

Robert Ramey