Path: utzoo!utgpu!attcan!uunet!seismo!sundc!pitstop!sun!amdcad!ames!mailrus!cornell!batcomputer!gdykes
From: gdykes@batcomputer.tn.cornell.edu (Gene Dykes)
Newsgroups: comp.windows.x
Subject: Re: Xtk "unsigned int" typedefs considered harmful
Message-ID: <6300@batcomputer.tn.cornell.edu>
Date: 13 Sep 88 16:05:12 GMT
References: <6289@batcomputer.tn.cornell.edu> <8809122025.AA00876@LYRE.MIT.EDU>
Reply-To: gdykes@tcgould.tn.cornell.edu (Gene Dykes)
Organization: Cornell Theory Center, Cornell University, Ithaca NY
Lines: 46

In article <8809122025.AA00876@LYRE.MIT.EDU> swick@ATHENA.MIT.EDU (Ralph R. Swick) writes:

Well, I hate to have to take on one of the heavyweights, but...

> Nowhere in the specification does it say that you may assume Dimensions
> and Positions are of any particular size.

Size of the variable is not an issue here - only signed vs. unsigned.

> If you want to write portable C code, you will have to use the (opaque)
> definitions of Dimension, Position and Cardinal and do the appropriate
> casts to get signed arithmetic where you want it.  It is quite possible
> that the spec should give a larger warning to C programmers.

I think you missed the point.

The point is that having Dimension, et.al., typedef'd as unsigned ints
has no redeeming virtue whatsoever, and in fact can cause the unsuspecting
programmer a lot of grief.  They should be typedef'd as int's and I suppose
the spec should say that the programmer can expect them to be usable
in expressions containing signed arithmetic.

Consider:

The things which have been declared with Dimension, Position, and Cardinal
can be reasonably expected to be involved in expressions with signed
arithmetic.  Furthermore, a variable which contains the difference between
two Dimensions ought to be declared a Dimension as well, and that can itself
be a negative number.  The only possible rationale I can think of for declaring
something unsigned int rather than int is if the variables are never expected
to be used in conjunction with signed arithmentic.  If one of those values got
so big that it needed another bit of precision, signed arithmetic won't work,
casts or no casts.

Well, there is another possible rationale:   "Let's see how much havoc we
can wreak by typedef'ing something contrary to its expected use..." :-)

Naturally, I prefer to think it was just a small oversight which can be set
straight with just a few seconds editing before R3 is shipped out.  I don't
see how this could have any backwards compatibility problems (except that the
meticulous programmers will have unnecessarily cluttered up there code with
a lot of extraneous casts.)


-- 
Gene Dykes, gdykes@tcgould.tn.cornell.edu