Re: 64 bit integers in Expat 2.0?
"Fisher, Paul_K (Houston)" <[email protected]>
| Newsgroups | gmane.text.xml.expat.general |
|---|---|
| Message-ID | <E9DE7963E5EA6546B42A979EC28B4D0111EBCBBE@hou-ex-02.adprod.bmc.com> |
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. paul -----Original Message----- From: [email protected] on behalf of Graham Bennett Sent: Tue 11/29/2005 4:19 PM To: Karl Waclawek Cc: [email protected] Subject: Re: [Expat-discuss] 64 bit integers in Expat 2.0? On Tue, Nov 29, 2005 at 09:00:46AM -0500, Karl Waclawek wrote: > > We are trying to decide whether we should change some API return values > to 64 bit integers to support file sizes > 2GB. Affected would be these > API members: > > XML_GetCurrentByteIndex() > XML_GetCurrentByteCount() > XML_GetCurrentLineNumber() > XML_GetCurrentColumnNumber() > > Obviously this requires applications to be recompiled. > > The question is, how "breaking" would that change be? > How many applications are actually using these members? > > Should this be delayed after the release of Expat 2.0? When you say change to 64-bit, do you mean explicitly 64-bit on all platforms? I would have thought it better to use something like size_t, which would be of the appropriate size on each platform. Graham -- Graham Bennett _______________________________________________ Expat-discuss mailing list [email protected] http://mail.libexpat.org/mailman/listinfo/expat-discuss