12-03-2022, 12:31 PM
On the flawed integer division, this is generated by the QB64PE compiler:
For 64-bit (in "libqb.cpp") it seems this definition is chosen:
This "qbr()" is used in a lot of places such as "PALETTE" and "PSET"... quite amusing.
Wait, shouldn't that huge hexadecimal number carry an "u" or "UL" or something like that? Why is it written in decimal while taking away from "f"?
Code: (Select All)
S_0:;
do{
tqbs=qbs_new(0,0);
qbs_set(tqbs,qbs_add(qbs_str((int64)(qbr( 1.5E+0 )/ 1 )),qbs_new_txt(" ")));
if (new_error) goto skip1;
makefit(tqbs);
qbs_print(tqbs,0);
qbs_print(nothingstring,1);
skip1:
...
For 64-bit (in "libqb.cpp") it seems this definition is chosen:
Code: (Select All)
#ifdef QB64_NOT_X86
int64 qbr(long double f) {
int64 i;
int temp = 0;
if (f > 9223372036854775807) {
temp = 1;
f = f - 9223372036854775808u;
} // if it's too large for a signed int64, make it an unsigned int64 and return that value if possible.
if (f < 0)
i = f - 0.5f;
else
i = f + 0.5f;
if (temp)
return i | 0x8000000000000000; //+9223372036854775808;
return i;
}
...
This "qbr()" is used in a lot of places such as "PALETTE" and "PSET"... quite amusing.
Wait, shouldn't that huge hexadecimal number carry an "u" or "UL" or something like that? Why is it written in decimal while taking away from "f"?