Re: 64 bit integers in Expat 2.0?
Karl Waclawek <[email protected]>
| Newsgroups | gmane.text.xml.expat.general |
|---|---|
| Message-ID | <[email protected]> |
Graham Bennett wrote: >On Tue, Nov 29, 2005 at 06:19:31PM -0500, Karl Waclawek wrote: > > >>Fisher, Paul_K (Houston) wrote: >> >> >> >>>It is certainly possible to have >2G of XML processed on a 32-bit platform, even if the doc is processed from file (large file support exists in modern OS versions.) >>> >>>I think that change proposed by Karl is a good one. If you changed the declaration to the moral equivalent of uint64_t (C99) then people with old code would get an integer truncation warning when they recompile against the new version. For Windows if you change the default DLL name most people will not fall into running previously compiled code against the new version. All reasonable to do on a major version change. >>> >>> >>> >>> >>> >>Actually, Rolf Ade suggested this as a feature request. >> >>Now here are the issues: >>- Expat 2.0 is supposed to be just the final, stable release of the >>1.95.x series. >> So introducing such a change that late might not seem appropriate. >>- On Windows, the library names have never had a version included. >> So, one solution could be to make it a compile time option, and have >> the default binary use the old compatible 32bit values. Later - post >>2.0 - we could >> remove the compile option and make 64bit values the default. >> >> > >Perhaps just having a separate set of 'long' functions corresponding to >each of the ones you listed but returning 64-bit types would be the >easiest way to go. > > Yes, that might be an option as well. It just doesn't feel "right" for me to add four new alternative API members when the original ones aren't used that often. API bloat? Karl