Compilation of BCC with legacy - math.c issues
GWRon opened this issue · comments
When compiling BCC with legacy BlitzMax then "math.c" contains some helpers for ctranslation.
blitz_string.c and .h (in blitz.mod) of "NG" and "vanilla" (or vanilla + "maxmods") contain different definitions for "bbStringToLong":
One fix (without tampering brl.mod of the legacy installation) would be to adjust math.c (but this then again makes it incompatible to ones with a newer blitz_string - like NG):
math.c
BBString * bmx_bitwise_not_longint(BBString * value, int size) {
if (size == 4) {
int v = bbStringToInt(value);
return bbStringFromInt(~v);
} else { // 8
//BBInt64 v = bbStringToLong(value); //NGs version
BBInt64 v;
bbStringToLong(value, &v);
return bbStringFromLong(~v);
}
}
BBString * bmx_binarymathexpr_longint(enum binaryOps op, BBString * slhs, BBString * srhs, int size) {
if (size == 4) {
...
case OP_OR:
res = lhs | rhs;
break;
}
return bbStringFromInt(res);
} else { // 8
//BBInt64 lhs = bbStringToLong(slhs); //NGs version
//BBInt64 rhs = bbStringToLong(srhs); //NGs version
BBInt64 lhs;
BBInt64 rhs;
Initially (when this feature was introduced - I think at least)
98a510d
there was a conditional to include math.c only for Non-NG
but then, with some other primitives added, this was changed to get included always:
b1013fd
a simple fix is to have two math.c (math_ng.c and math_legacy.c) and use them accordingly but this is surely still kinda error prone.
the alternative is to update "maxmods" for the new bbstringtolong
definition but this makes it a requirement for bcc-compilation-with-legacy-blitzmax then.