help-glpk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FW: [Help-glpk] bigmul in glblib05.c


From: Michael Hennebry
Subject: Re: FW: [Help-glpk] bigmul in glblib05.c
Date: Tue, 5 Jan 2010 12:44:01 -0600 (CST)
User-agent: Alpine 1.00 (DEB 882 2007-12-20)

On Tue, 5 Jan 2010, Andrew Makhorin wrote:

Run-Time Check Failure #1 - A cast to a smaller data type has
caused a loss of data. If this was intentional, you should mask
the source of the cast with the appropriate bitmask.  For
example:

char c = (i & 0xFF);

What this does is implementation dependent.

char c = (char)i;
char c = (char)(i & 0xFF);
char c = (char)(i & CHAR_MAX);
char c = (char)(i & UCHAR_MAX);
char c = (char)(unsigned char)i;
would all be better, but all still implementation dependent.
None should give you a warning.
They might give you five different results.
If chars are unsigned,
all except possibly the second will do what you probably want.
Life is more interesting if chars are signed.
C defines conversions from unsigned to
signed types only in their common range.
The others are implemenation defined.

This advice is helpful for quiche eaters only :)

Because MSVS 2008 would issue warning for such a conversion, the bigmul
is modified as

      union {
         unsigned int uint;
         struct { unsigned short ush1, ush2 ;} ush;
      } tuiush;
[...]
               x[i+j] = (unsigned short)tuiush.ush.ush1;

If preceded by an assignment to tuish.uint, it would be undefined behaviour.

--
Michael   address@hidden
"Pessimist: The glass is half empty.
Optimist:   The glass is half full.
Engineer:   The glass is twice as big as it needs to be."




reply via email to

[Prev in Thread] Current Thread [Next in Thread]