Herbert Duerr wrote: > I think that criticizing old rules that cause problems today by > causing bigger, slower, limited code which introduces extra > maintenance burdens and extra bugs from too tight types and signed-/ > unsigned issues is right on topic. Is this not the topic we are > talking about here? > Hi Herbert,
well, again just very slightly missing my point - see below ;)
> >[...] to permit ints and longs for everything
>
> Who wants that? If you need fixed-width types you need them... but
> even then using typedefs or or packing them into classes is often
> better.
>
> Anyway, I've stated my points. And I have a lot of experience to
> back them up. With that said I'm getting out of this discussion, I
> just don't have enough time.
>
Sorry to hear, maybe someone else is picking this up then - anyway:
so your suggestion is to use the native C ints by default, and
fixed-width types whenever there's a (recognized) need? And forcing
those fixed-width types into actual classes doing overflow,
underflow, and lossy conversion checking in non-pro builds?
If the answer is yes, then I think I have a decidedly bad feeling
about this - somewhat contrasting your experience mentioned above:
_everytime_ someone (preferrably exploiters) is putting integer math
to its limits inside OOo, there are bugs. Tons of them. Because
preventing overflows or truncation is non-trivial, even with fixed
ranges. Getting this right with only weak-relationed native int
sizes is even harder. So my (slightly amended) position on that
would be: iff the native ints are desirable (please scratch that
"bigger, slower ... code" from the first paragraph - that's truly a
red herring. For 99.9% of OOo's codebase), then let's make sure that
first off this dearly missed "what every computer scientist should
know about integer math" page is written. ;)
P.S.: case in point - X11 wire protocol:
struct _xPoint { INT16 x, y; };
X11 api:
struct XPoint { short x, y; };
Overflow handling: burdened on the app. Talk about transparency, and
POLS. XPoint being 'int' would have even been ok-ish, from an
abstraction perspective - 'short' is just a misguided attempt to
expose the INT16.
Cheers,
-- Thorsten
pgpWdGq2YUnJZ.pgp
Description: PGP signature
