My enterprise works with very large instance documents that are rich in tags. Currently some of our large documents are 750 MB and are growing fast as more data is added to the XML feeds and more users subscribe to our services.
If we went over 2/4/whatever GB limit that these 32-bit types impose, that would be very bad. Therefore I advocate making sure a library compiled as 64-bit shares the same traditional large file safety that people have come to expect in other 64-bit libraries. If this convention is not followed, what is the point of having 64-bit Xerces in the first place? Also, what happens if somebody makes a 5GB SVG file for some reason and then wants to manipulate it with Xerces? It would be disappointing to tell him/her that our library is not able to manipulate a conforming instance document! My two cents, Matt -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, June 10, 2005 12:01 PM To: [email protected] Subject: Re: Need for XMLSize_t? > > From what I see on Windows, at least, XMLSize_t ends up being a > > typedef > > for unsigned long, rather than size_t, and that's why I was concerned. > > I believe the intent of XMLSize_t is that it match whatever size_t > would be on a particular platform. size_t should be a 32 bit unsigned > on Win32, and 64 bits on Win64? Yes, it probably is a bug, but it's a bit of a problem on Windows, because the 64-bit model on Windows is different from most platforms in that long types are still 32-bits, so size_t is the only 64-bit integral type. On the other hand, from the usage I see, XMLSize_t might as well stay a 32-bit value, and probably should have been on all platforms. Do we really need to "count" more than 2^32 nodes in a document, or be able to index into more than 2^32 of character data? Dave --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___________________________________________________________________ The information contained in this message and any attachment may be proprietary, confidential, and privileged or subject to the work product doctrine and thus protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify me immediately by replying to this message and deleting it and all copies and backups thereof. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
