It's not a mask to stop data loss but to tell VS you want the data loss. I.E. unsigned short a = 0x1234; return (a << 8) & 0xffff; ------------------------------ Trevor R.H. Clarke tclarke at ball com Ball Aerospace & Technologies Corp -----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Daryle Walker Sent: Friday, December 16, 2005 1:37 PM To: Boost Users mailing list Subject: Re: [Boost-users] crc.hpp and visual studio run time checking On 12/16/05 1:04 PM, "Clarke, Trevor" 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" 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 _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users