> >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? Two comments: 1. wchar_t has the suffix "_t", but that suffix does not imply a "size". I think "XMLSize" is confusing with or without the "_t" suffix, so I don't understand your point. 2. Your example of passing off a memory leak is a straw-man. I am not advocating ignoring memory leaks or other serious bugs that affect all users. What I'm saying is that every change to the code needs to be evaluated based on a cost/benefit analysis. Usually, fixing a memory leak has a low cost and a very high benefit. And changing this typedef to size_t, or just changing the code to use size_t probably has a fairly low cost, because there are likely very few user-implementations of the DOM bindings, and has the benefit of clarifying the usage. > >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: Although I agree the choices for types were bad, you are talking about changes that have a very high cost, as they will break a huge amount of user code. Yes, they may "future-proof" the parser, but I question that users will be thrilled to change that much code for "future-proofing" they may not need. I don't think we've a single defect regarding the capacity of the parser or the DOM that relates to the use of 32-bit types for "sizes" or "counts." (And please, note I am not taking the position that this will never be case.) Thanks! Dave --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
