Hi Thorsten,
please see my answers below. I don't think the fixed-width types are a
hot topic that should get that much attention. Sounding the alarm on
the use of native types is not attention-worthy either. Especially
since the same reasoning got us worse code then, extra maintenance
burdens now and extra bugs from too tight types and bugs from unsigned/
signed-mixing issue.
your suggestion shows the fundamental flaw I've pointed out earlier
- that too much of the code makes implicit assumptions about the
available int ranges. Just grep for 0xFFFF, 0xFFFE etc. and weep.
The hardcoded range-checks were probably good enough then because of
the hardcoded types implied they would be safe forever. Changing any
of these signatures now is a lot of work with "lots of pain, little
gain". That's why it isn't high on anybodies priority list.
But if you need fixed-width types you should use them. But my
corollary is that if you don't need them you shouldn't be forced to
use them. Native types make code more pleasant to read. Code that is
written without hardcoded 16bit/32bit/etc. assumptions can and IMHO
should use native types.
Add to that performance implications - the Calc guys can likely tell
the story much better than me, how 'simple' increases in row/column
sizes affect overall speed.
Scalability problems are a different story. They show the same whether
allowing 64K instead of 32K or whether allowing 96K instead of 64K.
Of course changing old assumptions about reasonable ranges is hard as
we can see in the Calc's row and column limits, on Writer's paragraph
sizes, the number of resource IDs, etc. Nevertheless these limits
should not stay there forever.
When I look through other high profile multi-platform sources such
as gcc, the linux-kernel, etc. they have no problems to use native
types for everything except for interfaces defined by their ABI or
the API of the underlying platforms.
The kernel code presumably gets enough coverage with different int
sizes over the range of supported platforms, that such bad code gets
weeded out; besides I'm rather certain the kernel code is overall
much more defensive than OOo's. gcc is a different league, compiler
are usually no target for exploits.
Using non-native types doesn't make problems go away automatically. In
my experience it is quite the opposite:
With fixed-width types the ranges were often chosen extra-tight. E.g.
the artificial limit of 32K points in a tools polygon or your issue
#128078# where refcounters overflowed.
This tightness often causes their unsigned flavor to be used. Mixtures
of signed/unsigned types in calculations easily result in surprises,
which is why unsigned types are not supported in Java.
Ultimately, most of OOo's internal state stems from external input,
and since there's no designed firewalling e.g. around the binary
filters, I guess we're better safe than sorry, and not permit this
extra dose of platform dependency, for no apparent benefit.
See my historical examples on the use of sal_Int16, USHORT etc. Hard-
coding the internal interfaces to fixed-width types then results in
worse code today. If types with no implicit lengths were used, e.g.
intcoord instead
While I'm on the topic of exact-width integer types: Shouldn't we use
the types from <cstdint> instead? Is there any value-add left in the
sal_Int/USHORT/ULONG/etc. types, except as a marker that the code
hasn't been touched for a while?
Or should they get some value-add by e.g. in debug mode by them
becoming smart classes? With range checks, signed-unsigned checks,
cast-checks, etc.? Range checks should be simple. Maybe there is
already a generic template library for this? I haven't seen one
though. If I had to implement it I'd use type names close to the
cstdint typenames and switch the namespace depending on debug-mode or
product-mode.
---
Herbert Duerr
[email protected]
Registered Office: Sun Microsystems GmbH
Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Commercial register of the Local Court of Munich: HRB 161028
Managing Directors: Thomas Schroeder
Chairman of the Supervisory Board: Martin Haering
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
