My feeling is that #2 is the way to go.
This is based on experience with FreeBSD vs Linux where FreeBSD
took the route that they would upgrade all values to be 64-bit for 64-bit
platforms whereas Linux has taken the #3 route in places which has lead
to lots of confusion and subtle problems.
One solution is to go with #2, but to use size_t or our own type which would
scale from 32-bit to 64-bit. This assumes that there is interest in
using ATS
in embedded situations where either processor support or memory pressure
warrants not using 64-bit values everywhere. On a practical note, we could
make the API use the scaling type but not actually implement it through the
entire system (which would be a good deal of work, instead we would just
use 64-bits internally) so that we would not have to change the API
again *if*
we ever wanted to support embedded systems.
john
On 10/28/10 07:38, Leif Hedstrom wrote:
Hi all,
while looking at some issues we're having with InkAPI plugins, the
issue of 32-bit APIs on top of 64-bit data has come up again. I'd like
to bring this up for discussion again, and get suggestions and ideas
what we should do. It's quite unfortunate we didn't get these APIs
changed for v2.0 honestly, but I think we'll have to come up with some
plan.
Some ideas:
1) Don't do anything (other than fixing the bugs where we use
INT64_MAX to mean something, that gets foobared when returned as an INT).
2) Retrofit the InkAPIs to be int64 instead of int where necessary.
This breaks API compatibility.
3) Add new APIs where necessary, and keep the old 32-bit APIs as is.
E.g. today we have
int INKVIONBytesGet(INKVIO viop);
and we'd add something like
int INKVIONBytesGet64(INKVIO viop);
We would also have to fix the 32-bit APIs to at least work with the
64-bit INT64_MAX value and other overflow scenarios (just as #1).
Of these, #2 is the cleanest, while #3 is the least invasive (but,
means duplicating APIs).
Thoughts?
-- leif
