Hi Dave,
On Jun 8, 2005, at 9:33 AM, [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
