On Jun 13, 2005, at 4:36 PM, Scott Morgan wrote:
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.
Then the code is broken and needs fixing.
Scott,
Dave's contributions to the Xerces project, like many of ours, are on
a voluntary and time-available basis. I happen to agree with you, in
general, but I also very much respect Dave's perspective on this, as
he's had to deal with a lot of multi-platform integration issues.
For me the priorities on this would be as follows (from highest to
lowest priority):
(1) Fix XMLSize_t to be equal to size_t. That is the current
status quo in the Xerces 3.0 code not, admittedly, changed by
conscious choice but just because that's the way it got done when we
redid the typedefs—perhaps a reflection of the how strong the
association between those types is.
(2) Fix any negative performance/footprint characteristics that
emerge on 64 bit platforms due to this change. That might mean
introducing a new XMLCount as a typedef to unsigned long, and
beginning to adopt that for object counts where XMLSize_t is
currently improperly used. (But noting that XMLSize_t or, preferably,
say I, size_t should be used for byte counts).
(3) Adopt size_t and/or XMLCount more broadly to accommodate
shortcomings where unsigned int, for instance, is insufficient. In
particular, I'd much rather see some of the byte-oriented counts
moved from unsigned int to size_t.
For me, the fact that XMLSize_t lies is much worse than the fact that
some portions of our interface only accept 4GB byte counts (thus my
prioritization). But I understand Dave's concern that fixing the lie
will hurt performance. So I think we should do at least 1 & 2
together, probably.
Back to the volunteer aspect of things, however... You seem to feel
strongly about this, and would love it if you (or anyone else, for
that matter) felt up to generating a patch for it...
And finally (to get back to my first question in this thread), I'd
love to suggest that where possible (and while making any additions
or alterations to the API) that we simply use size_t for byte counts
instead of XMLSize_t. Since size_t has been proven to be available on
all of our platforms (we use it raw in a number of areas) the
clearest thing of all would simply be to use it, rather than any alias.
Jaems
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
