Re: [boost] Official warnings policy?

Subject: Re: [boost] Official warnings policy?
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2009-11-12 14:07:09

Emil Dotchevski wrote:
> On Thu, Nov 12, 2009 at 9:58 AM, Stewart, Robert
> <Robert.Stewart_at_[hidden]> wrote:
> > Emil Dotchevski wrote:
> >
> > If the purpose of the test is to show that variant triggers the same
> > warning as would an ordinary int-to-short assignment, getting the
> > warning here is a good thing.
> >
> > If the purpose of the test is to prove that assigning to variant has
> > the same runtime behavior as non-variant code, as I suggested
> > above, the warning is unwarranted noise.
>
> Lets assume it's the latter. Still, I don't think it is fair to label
> the warning as unwarranted noise. It would be noise if there were 200
> warnings reported from this test. Somewhere between 1 and 200,
> warnings can be classified as additional information, not noise.
>
> If a warning tells you that the code is incorrect (as in, you should
> have used short instead of int for the type of a given variable) then
> sure, it should be fixed. If it tells you that your correct code might
> be wrong, then seeing the warning is a good thing -- unless it becomes
> annoying at which point it is silenced for the sake of sanity.

In that case, the warning is noise.  The test is using a small integer value that can be verified to fit in a short on any supported platform (is there a platform that wouldn't hold 58 in a short?).  Having determined that 58 is a safe value for the int-to-short assignment test, one should silence the warning.  Its continuing presence merely causes each person noticing it to examine the test to determine whether the warning is referring to a legitimate concern.

If the purpose of the test were to show that the assignment produces a warning as with non-variant code, then it would need to be documented accordingly so those noticing the warning can see that it is expected.  Indeed, one might want an official Boost warnings-as-errors build mechanism to build normally and then scan for warnings after the fact, compare them to an expected warnings list, and report warnings not on the list rather than building with the warnings-as-errors flag.  With that mechanism, such a test would be marked as producing an expected warning and the warning would not appear in the reported build status.

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