[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: minus operator applied to unsigned type
>>> d_val = str == '-' ? -(double)-l_val : (double)l_val;
>> I'm not sure why the -(double)-l_val construct. I suspect the
>> intent is to convert an unsigned long holding a signed long's bit
>> pattern to a double with the same value as the signed long.
> Yes, that's what I assumed, and I believe that the original code
> correctly implements that intent.
Hm. I convinced myself the antipode of zero was an exception.
Thinking about it now, I don't think it is. I'd have to think more
about cases where signed long can't represent exactly as many values as
If it really is a "we have the bit pattern, reinterpret it" then the
correct thing is something like (double)*(long *)&l_val.
If l_val was created by assignment from a signed long, though, rather
than a "take the bits as" operation, it may not have the same bit
pattern and something like this dance is needed.
>> If so, I can't see why not (double)(long)l_val;
> That invokes undefined behaviour, if l_val is an unsigned long whose
> value is outside the range of positive integers that that can be
> represented by a signed long.
Well...not quite; implementation-defined != undefined. 220.127.116.11 [#3]:
"Otherwise, the new type is signed and the value cannot be represented
in it; either the result is implementation-defined or an
implementation-defined signal is raised.".
Admittedly, this is pretty close to the same thing as far as code
portability is concerned...though bmake may be content to write off
portability to machines/compilers where conversion from unsigned long
to long isn't the inverse mapping of the conversion the other way. I'd
certainly give any such system a good hard look before trusting it to
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Main Index |
Thread Index |