> >>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. > > > > That's still no excuse for inconsistent naming, XMLSize_t implies a > size_t type (unsigned int/long only on systems that don't support > size_t, pretty rare these day) otherwise it should be just plain XMLSize
> or something else like XMLLen to avoid any confusion. Basicly, XMLSize_t > for byte lengths (MemBufInputSource for example) XMLSize/XMLLen for node > counts and similar (like DOMNodeList). 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. 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. Dave --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
