Re: minus operator applied to unsigned type

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>>>     d_val = str[0] == '-' ? -(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
unsigned long.

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.  6.3.1.3 [#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
do anything.

/~\ 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