[EMAIL PROTECTED] wrote:
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).
It may be an unexciting refactoring effort to go through the various
classes and functions and fix this but a more consistent API will be
beneficial in the long run for everybody. The whole point of typedefs it
to give meaningful names to variable types, the current XMLSize_t mess
fails this by being misleading.
Scott Morgan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
