Re: [boost] [units] gcc warnings

Subject: Re: [boost] [units] gcc warnings
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-06-16 13:16:47

Emil Dotchevski wrote:
> On Wed, Jun 16, 2010 at 4:00 AM, Stewart, Robert
> <Robert.Stewart_at_[hidden]> wrote:
> > Emil Dotchevski wrote:
> >> Integer implicit conversions specifically are very common in C and
> >> C++. For example, incrementing a short int results in two implicit
> >> conversions, one of which might lead to truncating the
> >> value. That is about as safe (or unsafe) as the code in question,
> >> so why nobody cares about that case? Answer: because the compiler
> >> doesn't warn.
> >
> > No, it is because increment has well defined behavior for
> > short that doesn't require a warning.  The code in question
> > could have generated -- but doesn't presently -- a value
> > that wouldn't fit in the target type leading to a
> > misinterpretation of the result.
>
> AFAIK the semantics of incrementing a short are that its value is
> first implicitly converted to int, which is then incremented (as an
> int), and then the int result is truncated (assuming
> sizeof(short)<sizeof(int)) back to short.

That's roughly how it works, yes.  Overflow is well defined for unsigned types (3.9.1/4 and 4.7/2), but not signed (4.7/3), so it is possible to overflow s and not know the result portably (because 4.7/3 says the result is implementation defined).

Since signed overflow is implementation defined, even without the int-to-short conversion, incrementing a short is a problem.

> As far as warnings are concerned, shouldn't this be treated
> identically to the case when the truncated value was an int
> to begin with?

Yes, that could just as easily warrant a warning.  Practically speaking, it would be most annoying, though it would encourage using int rather than short!

> >> If you don't want your compiler to issue a particular
> >> warning, a type cast should be the last solution to reach
> >> for, IMO.
> >
> > It certainly appears that the types can be adjusted to
> > alleviate the problem in this case, but that isn't always
> > possible as impedance mismatches occur that cannot be
> > altered.  In such cases, a static_cast, which *should*
> > indicate that the developer examined the code in question
> > and has decided that the potential for truncation is not
> > an issue
>
> Disabling the warning locally would indicate that the developer
> examined the code, but (importantly) the program remains unchanged.

That isn't possible for all compilers and isn't portable for those that support the feature.  That makes it much less than ideal unless only those compilers complain.

> Using static_cast is not the same as disabling the warning locally;
> for example, if a future remote edit changes the type of the object

I suggested an assertion in addition to the static_cast to verify the behavior as a defense against maintenance effects.  Assuming the type is always short, then asserting the current value less-than std::numeric_limits<short>::max() would suffice.  To account for your change of type scenario, a compile-time assertion that the type is short would also be needed.

> being converted, static_cast may inhibit a compile error.

I don't see how static_cast would be able to hide an error.

> Even more ill-advised is instead of static_cast<T>(x) to use the
> functional notation syntax T(x) which in some cases has the semantics
> of a C-style cast which is even more likely to inhibit a compile
> error.

Did we allow for C-style casts in this discussion?  I don't think so.  I almost never use them.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.