I propose that we change
ink64 -> int64 inku64 -> uint64 ink32 -> int32 inku32 -> uint32 ink16 -> int16 inku16 -> uint16 ink8 -> int8 inku8 -> uint8 because 1) we decided to move from ink -> ts 2) tsu64 doesn't scan like an integer 3) int64_t is long on linux which is incompatible with %lld the only standard and universally compatible way to read/write a 64-bit number 4) int64 is similar but not the same as ink64_t and it scans well 5) I tried it and it works! john On 5/19/2010 7:06 AM, Leif Hedstrom wrote: > On 05/19/2010 04:17 AM, Mladen Turk wrote: >> On 05/19/2010 08:25 AM, John Plevyak wrote: >>> >>> I hate to say it, but the simplest thing is >>> to use long long int for all this junk. In practice >>> that is what it is on most systems, or at >>> least that covers their useful range. >>> >> >> Agreed. >> Think that Leif is working on 64-bit file API, and >> forcing that for both 32 and 64 bit systems would >> certainly simplify the need for casting. > > Yeah. All my changes are using ink64 though, and %lld when using one of > the formatted output APIs. I figured it'd be easy to change that later > if/when we decide to change types. > > -- Leif
