Compilation of BCC with legacy - math.c issues

[GWRon]

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.