> I think it was originally needed only for the CRC code, so we put it
> there to begin with. Clearly should be in a more widely used place now.
> Do you have any opinion whether c.h or int8.h is the Right Place?
> I'm still dithering about that.
In looking at the code, istm that the versions should be merged with
features from both. The generated constants should be surrounded in
parens, but the explicit coersion to (int64) should be omitted at least
with the "LL" version.
I've got some other "int64" pushups to worry about; let's try fixing
those too (though afaict they may need to happen in different places).
At the moment, we have INT64_IS_BUSTED as an amalgam of other conditions
or undefined variables. I've also got a HAVE_INT64_TIMESTAMP which comes
from a configured variable USE_INTEGER_DATETIMES and an undefined
INT64_IS_BUSTED. This is now housed in c.h, but istm that we *should*
check for conflicting settings in configure itself, and carry forward a
consistant set of parameters from there.
Anyway, at the moment some of this stuff is in c.h, and that is probably
the right place to put the INT64CONST definitions, at least until things
sort out differently.
btw, I've updated gram.y and variable.c to suppress the reported
warnings (which I *still* don't see here; that is very annoying).
- Thomas
