You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by James Berry <jb...@apache.org> on 2005/06/08 15:20:19 UTC
Need for XMLSize_t?
Xerces defines XMLSize_t (to size_t, generally), and uses it in some
places. It also uses just a raw size_t in other places.
Since we seem to have been surviving fine with a plain size_t, I'd
like to suggest that we eliminate XMLSize_t in favor of size_t
everywhere in Xerces 3.0. This would eliminate a bit of required
configuration.
Any discussion?
-jdb
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Need for XMLSize_t?
Posted by Scott Morgan <bl...@blueyonder.co.uk>.
James Berry wrote:
> 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.
I'm sorry to come over a bit harsh on this, I don't mean to. I'm just a
bit exasperated at the lack of foresight on this issue, there seems to a
be a few too many places where incorrect var types are used. The longer
this is left the harder it will be to fix.
> 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.
> (2) Fix any negative performance/footprint characteristics that
> emerge on 64 bit platforms due to this change.
> (3) Adopt size_t and/or XMLCount more broadly
>
> 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.
I totally agree, particularly about the XMLSize_t != size_t issue,
misleading or ambiguous code make life harder for everybody.
> 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...
Would be an excuse to try the new SVN repository, I'll pull head tonight
and have a look.
Scott Morgan
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Need for XMLSize_t?
Posted by James Berry <jb...@apache.org>.
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: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Need for XMLSize_t?
Posted by da...@us.ibm.com.
> >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".
Frankly, 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: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Need for XMLSize_t?
Posted by da...@us.ibm.com.
> >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: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Need for XMLSize_t?
Posted by Scott Morgan <bl...@blueyonder.co.uk>.
david_n_bertoni@us.ibm.com wrote:
>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?
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.
>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:
MemBufInputSource
<http://xml.apache.org/xerces-c/apiDocs/classMemBufInputSource.html#z216_0>
(const XMLByte
<http://xml.apache.org/xerces-c/apiDocs/XercesDefs_8hpp.html#a16> *const
srcDocBytes, const unsigned int byteCount, const XMLCh *const bufId,
const bool adoptBuffer=false, MemoryManager
<http://xml.apache.org/xerces-c/apiDocs/classMemoryManager.html> *const
manager=XMLPlatformUtils::fgMemoryManager
<http://xml.apache.org/xerces-c/apiDocs/classXMLPlatformUtils.html#z488_4>)
unsigned int for a byte count is wrong, particularly on 64 bit systems.
It doesn't matter if it means changing a load of var types in the code,
the code is wrong and needs fixing. There needs to be a clear
differentiation between memory sizes (size_t) and counts (i.e. number of
nodes), the API needs to reflect this by having and using XMLSize_t
correctly, as a platform safe alias for size_t, idealy a new type
XMLLen/XMLCount/whatever needs to be added for situations like node
counts. This would help future proof Xerces and make clear to developers
what ranges to expect when dealing with the lib.
Scott Morgan
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Need for XMLSize_t?
Posted by da...@us.ibm.com.
> >>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: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Need for XMLSize_t?
Posted by Scott Morgan <bl...@blueyonder.co.uk>.
david_n_bertoni@us.ibm.com 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: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Need for XMLSize_t?
Posted by Axel Weiß <aw...@informatik.hu-berlin.de>.
david_n_bertoni@us.ibm.com 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. Look at all of the string functions in
> XMLString:
Hi Dave,
I would not at all mind changing widespread code in order to correct
design errors. We move towards a new release, so it's now to take the
chance to do it!
> static unsigned int stringLen(const XMLCh* const src);
Clearly, this (and it's sisters) is poorly designed. 'stringLen' really
should return size_t, or XMLSize_t, respectively (see below).
> 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.
What is more dangerous: making a mistake apparent - or conceil it?
I see it my way[tm]: during the past decade, there was no strong reason
to distinct between unsigned int and size_t (both were 32-bit, except
for some smaller embedded or dsp platforms, which are of no interest
here). Programmers (including myself!) tended to become insensitive for
the different semantics of these unsigned types and mixed them up here
and there.
Now, some 64-bit architectures arise and bring some new light into the
scene. Suddenly, there's big confusion about 'unsigned int' or even
'unsigned long' to be not sufficient any more to hold a
pointer-difference. The only chance I can see to become compatible again
with these systems is to revise every piece of code and use the correct
types, according to their semantics.
> > 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.
I'm feeling misunderstood at this point, Dave. Allow me to argue a bit
more in detail.
I'd like to distinct three items here:
- limitation by hardware (1)
- limitation by software (2)
- limitation by standards (3)
(1) is a limitation that may vary with time
(2) is the only limitation that is visible through the api
(3) is fixed, stable and 'provable'
Then, 'conforming' software should likely behave as follows:
- it should detect and respect the hardware limitations (1) in order not
to fail on a particular platform
- it should identify absolute limitations defined by the standards (3)
and adjust it's own limitations (2) to reflect them in the api
- for all others, it should scale it's own limitations (2) to reflect (1)
In terms of the above, a DOM implementation would be non-conforming, if
it would set some limits by it's own (2), regardless the underlying
harware limits (1), which are no explicit standard limits (3).
It would be conforming, if it's own limits (2) either reflect standard
limits (3) or always scale with the underlying hardware limits (1).
What I want to find is:
- If we find in the xml specs an explicit, absolute limit (3) for the
number of elements a DOMDocument may contain, we could set an absolute
limit (2) to the datatype that counts DOMElements (e.g. 32-bit).
- If we can't find such a limit (I think, we definitely won't), we should
carefully scale to the hardware limits (1) of a datatype that counts
entities (maybe size_t here).
And, regarding to XMLSize_t:
- If we find in the xml specs an explicit, absolute limit (3) for the
length an XMLString may have, we could set an absolute limit (2) to the
datatype that measures stringLen (e.g. 32-bit).
- If we can't find such a limit, we should carefully scale to the
hardware limits (1), and that's size_t.
In my reading, the xml standatds don't have a 32-bit limit (3) for string
length. Then, using 'unsigned int' to represent string lengths, clearly
is a design error and should be corrected, e.g. be replaced by
size_t/XMLSize_t.
> > 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.
(I only made a side note here. Maybe your customers will learn this
soon ;)
Cheers,
Axel
--
Humboldt-Universität zu Berlin
Institut für Informatik
Signalverarbeitung und Mustererkennung
Dipl.-Inf. Axel Weiß
Rudower Chaussee 25
12489 Berlin-Adlershof
+49-30-2093-3050
** www.freesp.de **
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Need for XMLSize_t?
Posted by da...@us.ibm.com.
> 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: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Need for XMLSize_t?
Posted by Axel Weiß <aw...@informatik.hu-berlin.de>.
david_n_bertoni@us.ibm.com wrote:
> On the other hand, from the usage I see, XMLSize_t might as well stay
> a 32-bit value, and probably should have been on all platforms. Do we
> really need to "count" more than 2^32 nodes in a document, or be able
> to index into more than 2^32 of character data?
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.
In the past, similar questions have proven to poorly fail. Whenever an
upper bound of some measure has been placed in terms of absolute numbers
(stating that no one could imagine that this upper bound practically
would ever be excessed), this bound has become the Achilles' heel one
decade later. A consequence of Moore's law.
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.
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.
Axel
--
Humboldt-Universität zu Berlin
Institut für Informatik
Signalverarbeitung und Mustererkennung
Dipl.-Inf. Axel Weiß
Rudower Chaussee 25
12489 Berlin-Adlershof
+49-30-2093-3050
** www.freesp.de **
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Need for XMLSize_t?
Posted by da...@us.ibm.com.
> > From what I see on Windows, at least, XMLSize_t ends up being a
> > typedef
> > for unsigned long, rather than size_t, and that's why I was concerned.
>
> I believe the intent of XMLSize_t is that it match whatever size_t
> would be on a particular platform. size_t should be a 32 bit unsigned
> on Win32, and 64 bits on Win64?
Yes, it probably is a bug, but it's a bit of a problem on Windows, because
the 64-bit model on Windows is different from most platforms in that long
types are still 32-bits, so size_t is the only 64-bit integral type.
On the other hand, from the usage I see, XMLSize_t might as well stay a
32-bit value, and probably should have been on all platforms. Do we
really need to "count" more than 2^32 nodes in a document, or be able to
index into more than 2^32 of character data?
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Need for XMLSize_t?
Posted by James Berry <ja...@jberry.us>.
On Jun 10, 2005, at 9:02 AM, david_n_bertoni@us.ibm.com wrote:
> From what I see on Windows, at least, XMLSize_t ends up being a
> typedef
> for unsigned long, rather than size_t, and that's why I was concerned.
I believe the intent of XMLSize_t is that it match whatever size_t
would be on a particular platform. size_t should be a 32 bit unsigned
on Win32, and 64 bits on Win64?
If our Windows headers typedef XMLSize_t to anything but "size_t", I
would think that's a bug...?
-jdb
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Need for XMLSize_t?
Posted by da...@us.ibm.com.
> > Yes, I'm aware of what size_t and ptrdiff_t are, but that's not my
> > real
> > concern. I'm worried we are removing an existing typedef that
> > users might
> > have in their code, which means they will face modifying their
> > code. Also,
> > we might be changing the semantics of our code and their code without
> > understanding the consequences.
>
> Yes, removing a typedef that will force changes in code is a valid
> concern. I guess we have to weight that against the fact that we're
> continuing to perpetuate an additional type, for which a standard
> type already exists, and which may cause a need for additional casts,
> etc, in using our code.
I always hate doing something that breaks source-code compatibility,
especially with a typedef.
> As far as the semantics thing goes, I don't think there's a problem
> as far as sizing, but I could be wrong ;)
>From what I see on Windows, at least, XMLSize_t ends up being a typedef
for unsigned long, rather than size_t, and that's why I was concerned.
Thanks!
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Need for XMLSize_t?
Posted by James Berry <ja...@jberry.us>.
Hi Dave,
On Jun 8, 2005, at 9:33 AM, david_n_bertoni@us.ibm.com wrote:
>> In any case, size_t is defined by the standards as a type that will
>> hold "an unsigned integral type of the result of the sizeof
>> operator." So it needs to be able to accommodate the size of anything
>> stored in memory. It's like ptrdiff_t, only unsigned. Where ptrs are
>> actually 64 bits, size_t needs to be too. I believe XMLSize_t is
>> already defined on our platforms to be 64 bits in those situations,
>> though somebody is free to argue me wrong ;)
>>
>
> Yes, I'm aware of what size_t and ptrdiff_t are, but that's not my
> real
> concern. I'm worried we are removing an existing typedef that
> users might
> have in their code, which means they will face modifying their
> code. Also,
> we might be changing the semantics of our code and their code without
> understanding the consequences.
Yes, removing a typedef that will force changes in code is a valid
concern. I guess we have to weight that against the fact that we're
continuing to perpetuate an additional type, for which a standard
type already exists, and which may cause a need for additional casts,
etc, in using our code.
As far as the semantics thing goes, I don't think there's a problem
as far as sizing, but I could be wrong ;)
In any event, this is not a big issue for me...I simply noticed that
it seemed pointless to have this extra type, and thought I'd throw it
out for comment. The work to support it in autoconf is already
complete...it would be more work to remove it, etc...but might make
for a cleaner API.
> By the way, I've gotten much farther with the Solaris builds, and
> I'll try
> to put together an email later with the details. Overall, the new
> build
> system seems so much cleaner!
Great to hear. I can't wait to see the details.
James
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Need for XMLSize_t?
Posted by da...@us.ibm.com.
> In any case, size_t is defined by the standards as a type that will
> hold "an unsigned integral type of the result of the sizeof
> operator." So it needs to be able to accommodate the size of anything
> stored in memory. It's like ptrdiff_t, only unsigned. Where ptrs are
> actually 64 bits, size_t needs to be too. I believe XMLSize_t is
> already defined on our platforms to be 64 bits in those situations,
> though somebody is free to argue me wrong ;)
Yes, I'm aware of what size_t and ptrdiff_t are, but that's not my real
concern. I'm worried we are removing an existing typedef that users might
have in their code, which means they will face modifying their code. Also,
we might be changing the semantics of our code and their code without
understanding the consequences.
By the way, I've gotten much farther with the Solaris builds, and I'll try
to put together an email later with the details. Overall, the new build
system seems so much cleaner!
Thanks!
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Need for XMLSize_t?
Posted by James Berry <ja...@jberry.us>.
On Jun 8, 2005, at 8:59 AM, david_n_bertoni@us.ibm.com wrote:
>> Since we seem to have been surviving fine with a plain size_t, I'd
>> like to suggest that we eliminate XMLSize_t in favor of size_t
>> everywhere in Xerces 3.0. This would eliminate a bit of required
>> configuration.
>>
>
> We should be careful to understand the implications of this before
> we do
> it. For example, in the Windows 64-bit model, size_t is 64 bits, but
> unsigned long is 32-bits. How will that affect users' code, and
> will it
> unnecessarily bloat the size of the DOM instances on some platforms?
My understanding of XMLSize_t is that it was added to accommodate (or
potentially accommodate?) platforms that had no standard size_t
definition. It has typically been typedef'd to size_t. But since we
seem to be using plain size_t with no problems, I see no need to
continue perpetuating XMLSize_t.
In any case, size_t is defined by the standards as a type that will
hold "an unsigned integral type of the result of the sizeof
operator." So it needs to be able to accommodate the size of anything
stored in memory. It's like ptrdiff_t, only unsigned. Where ptrs are
actually 64 bits, size_t needs to be too. I believe XMLSize_t is
already defined on our platforms to be 64 bits in those situations,
though somebody is free to argue me wrong ;)
James.
>
> But I do agree that its use is pretty much limited to the DOM, and
> I don't
> quite understand the purpose of it, or all of the preprocessor macro
> definitions (_SIZE_T, SIZE_MAX, etc.) that go along with it.
>
> Thanks!
>
> Dave
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: c-dev-help@xerces.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Need for XMLSize_t?
Posted by da...@us.ibm.com.
> Since we seem to have been surviving fine with a plain size_t, I'd
> like to suggest that we eliminate XMLSize_t in favor of size_t
> everywhere in Xerces 3.0. This would eliminate a bit of required
> configuration.
We should be careful to understand the implications of this before we do
it. For example, in the Windows 64-bit model, size_t is 64 bits, but
unsigned long is 32-bits. How will that affect users' code, and will it
unnecessarily bloat the size of the DOM instances on some platforms?
But I do agree that its use is pretty much limited to the DOM, and I don't
quite understand the purpose of it, or all of the preprocessor macro
definitions (_SIZE_T, SIZE_MAX, etc.) that go along with it.
Thanks!
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org