Re: [Boost-users] crc.hpp and visual studio run time checking

From: Daryle Walker (darylew_at_[hidden])
Date: 2005-12-16 13:36:50

On 12/16/05 1:04 PM, "Clarke, Trevor" <tclarke_at_[hidden]> wrote:

> The problem is that the code does not state that it doesn't care if those bits
> disappear (via masking) so a warning is thrown stating that you are loosing
> data. Similar to compiler warnings if you do this:
> 
> int foo(123456789);
> char bar = foo; // instead of bar = static_cast<char>(foo);
> 
> The difference is, the masking warning is a run time check which pops up a
> dialog every time the code executes and is thus not as easy to ignore as the
> compile warning.

If we do:

    int32  g = 0x01234567;
    assert( g << 8 == 0x23456700 );

The "01" part has already been shifted away.  No amount of masking will fix
the data loss that has already occurred.  Or do you mean to mask first:

    assert ( (g & 0x00FFFFFF) << 8 == 0x23456700 );

which gets rid of the "01" part, resetting it to zero, before obliterating
it with the shift?  All the mask would do is shut up the RTC from a nuisance
warning; it doesn't add any worth to the code.  Is there something like a
"#pragma disable" to shut up RTC around this code, or would you have to
deactivate RTC?

> -----Original Message-----
[I wrote (on 2005-12-16T12:38)]
>> On 12/14/05 2:32 PM, "Clarke, Trevor" <tclarke_at_[hidden]> wrote:
>> 
>>> There are a few places in crc.hpp where the following happens:
>>> static  value_type  shift( value_type rem )
>>>          { return rem << CHAR_BIT; }
>>> 
>>> The problem is, if run time checking is active in VS2003 (I assume 2005 has
>>> the same issue), a pop-up warning is issued during every call to the
>>> function as data is lost. (that¹s the intent in fact). The fix is to mask
>>> (rem << CHAR_BIT) & 0xffff  (or whatever the appropriate mask value is for
>>> value_type). Is this a known issue? It¹s technically not a bug but could
>>> cause some annoyances for anybody using rtc. Should this be changed?
>> 
>> What's the point of the mask?  The affected bits have already gone to
>> oblivion at that point.  Maybe RTC has a bug?

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT hotmail DOT com