[EMAIL PROTECTED] wrote:
I am not trying to defend the chosen name for this typedef (In fact, I would not have chosen this name to begin with). I'm simply trying to point out that it's naive to think making this a synonym for size_t will not have implications.
It's still a bug. XMLSize_t implies a size_t type (why else have the _t ending?), this is misleading and very bad practice for an API. Changing it to correctly represent size_t will have consequences, but that's what happens when fixing a widespread bug. You wouldn't sit back and pass off a memory leak just because fixing it would have implications would you? Why go easy on this bug? Fixing it will make things better in the long run, you'll avoid some poor sap in the future hitting a wall when his XML file breaches an artificial 32-bit barrier because of bad practice today.
The bulk of the parser code uses unsigned int for most "sizes" and "counting." On 64-bit platforms, size_t will be larger than unsigned int, meaning that the bulk of the parser code will out-of-synch with XMLSize_t.
Then the code is broken and needs fixing. Take MemBufInputSource for instance:
MemBufInputSource <http://xml.apache.org/xerces-c/apiDocs/classMemBufInputSource.html#z216_0> (const XMLByte <http://xml.apache.org/xerces-c/apiDocs/XercesDefs_8hpp.html#a16> *const srcDocBytes, const unsigned int byteCount, const XMLCh *const bufId, const bool adoptBuffer=false, MemoryManager <http://xml.apache.org/xerces-c/apiDocs/classMemoryManager.html> *const manager=XMLPlatformUtils::fgMemoryManager <http://xml.apache.org/xerces-c/apiDocs/classXMLPlatformUtils.html#z488_4>)
unsigned int for a byte count is wrong, particularly on 64 bit systems. It doesn't matter if it means changing a load of var types in the code, the code is wrong and needs fixing. There needs to be a clear differentiation between memory sizes (size_t) and counts (i.e. number of nodes), the API needs to reflect this by having and using XMLSize_t correctly, as a platform safe alias for size_t, idealy a new type XMLLen/XMLCount/whatever needs to be added for situations like node counts. This would help future proof Xerces and make clear to developers what ranges to expect when dealing with the lib.
Scott Morgan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
