Convert 1 to 1.0, not 0.0, for machines with 64-bit long.
This fixes flt_arith2flt() when sizeof(arith) != 4, where arith is long. When cemcom.ansi sees an expression like d + 1 (where d is some double), it calls flt_arith2flt() to convert 1 to floating-point. On machines where sizeof(arith) != 4, the code did n >>= 1 when n should not have been changed. If n was 1, then n == 0 became true. This caused the code to convert 1 or -1 to 0.0. My fix assumes sizeof(arith) >= 8, so I can use n >> 32. Machines with sizeof(arith) of 5 to 7 would need to do (uarith)n >> 32, where uarith must be an unsigned integer type of same size as arith. In startrek.c, the Enterprise can now dock with a starbase. The compiler no longer translates s1 - 1 to s1 - 0.0 and s1 + 1 to s1 + 0.0, so the game now looks for starbases next to the Enterprise.
This commit is contained in:
parent
08f9869a63
commit
e5e96d5226
|
@ -25,10 +25,9 @@ flt_arith2flt(n, e, uns)
|
|||
e->m1 = 0; e->m2 = n;
|
||||
}
|
||||
else {
|
||||
e->m2 = n & 0xffffffffL;
|
||||
n >>= 1;
|
||||
n &= ~((arith) 1 << (8*sizeof(arith)-1));
|
||||
e->m1 = (n >> 31);
|
||||
/* assuming sizeof(arith) >= 8 */
|
||||
e->m1 = n >> 32;
|
||||
e->m2 = n;
|
||||
}
|
||||
if (n == 0) {
|
||||
e->flt_exp = 0;
|
||||
|
|
Loading…
Reference in a new issue