> I would vote for not to limit XMLSize_t (or any other 'measuring' type)
> to a fixed bit value. Instead, it should exactly shadow size_t.
Well, the we'ed better be prepared to change code all over the parser.
XMLSize_t is used only in the new DOM. Almost everywhere else, unsigned
int is used. Look at all of the string functions in XMLString:
static unsigned int stringLen(const XMLCh* const src);
static int indexOf(const char* const toSearch, const char ch);
In fact, you can see some of these functions return int, which even
further restricts the length of a string.
the SAX interfaces:
virtual void
ContentHandler::characters
(
const XMLCh* const chars
, const unsigned int length
) = 0;
Given that, I don't think it's very useful, and could even be dangerous,
to have XMLSize_t be a synonym for size_t.
> And we do not know today how many nodes some xml document will carry in
> 2015. But: xerces should be conform with the xml standards, and AFAIK
> w3c has no 32-bit limit for the number of nodes in a document.
Any implementation will have limitations. Are you saying a DOM
implementation on a 32-bit platform is non-conforming because it limits
the number of nodes in a document? In fact, the official DOM IDL bindings
_do_ have explicit sizes for all types, so the limitations are explicit as
well.
> The problem of blowing the DOMNode representation on 64-bit systems is
> not as grave as it seems on a first sight. Systems grow as they grow -
> everybody knows that 64-bit software take more memory than their 32-bit
> equivalents - and uncomplainingly slots in double RAM.
I dispute the notion that everyone's customers "knows that 64-bit software
take more memory than their 32-bit equivalents" and that they
"uncomplainingly slots in double RAM." Perhaps your customers do this
uncomplainingly, but many of mine do not.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
