Was |int| always thought to be 32bit ?

[Jim Gettys]

Here's the historical (hysterical?) scoop.

Back in the '80's, there were C compilers particularly on PC's in which
sizeof(short)=sizeof(int) = 16, with sizeof(long)=32.

Most workstations of the era had sizeof(short=16), sizeof(int)=32,
sizeof(long=32).

In X10 and before, we had numerous bugs of form passing an address of a
short to a function, the value of the short being presumed to be an int,
and resulting bugs.  C compilers weren't all that great about type
checking, and tools like lint were broken on many/most platforms at the
time.

To reduce the number of random portability bugs, we decided to make most
items in the X11 public interface ints, to avoid these bugs, only
retaining shorts in structures like points and lines...

			- Jim



 

On Tue, 2005-04-26 at 04:48 +0200, Roland Mainz wrote:
> Egbert Eich wrote:
> >  > While looking at the X11 headers I see that some structure members and
> >  > function arguments and return values use |int| - was that datatype
> >  > thought to be always 32bit or is there any platform which used 16bit for
> >  > |int| to work with X11 code (client side+Xserver), too (parts of the
> >  > code use |short| to explicitly say "... it's 16bit..." but I cannot find
> >  > a clear statement was |int| should be...) ?
> > 
> > Appearantly at one time there used to be X implementations for DOS
> > where int was 16bit unless you used a DOS extender and ran in protected
> > mode. I'm not sure if any Xserver implementation was real mode, though.
> > The use of short as 'it's 16bit' is rather poor. Fixed sizes should
> > be taken form system headers where avaialble or defined in an X header.
> 
> AFAIK all C implementations take |short| as 16bit. Originally (before
> 64bit machines were "invented") |long| was 32bit and |int| was a
> datatype which picked the "natural" representation of an integer for
> this machine type (or better: the representation which was the fastest
> or "best" for register/memory access) ...
> 
> > A bigger problem however arises from the careless interchange of int
> > and long in some parts of the code.
> > It makes the VSW4 test suite fail in some tests (one even ends up in
> > an endless loop) on 64bit BE platforms.
> 
> Was there ever filed a bug for that ?
> 
> > Since the problem exists in the server drawable structure a fix would
> > either break the internal server ABI or would require to hand cast
> > assignments all over the code :-(
> 
> It may be better to cleanup the code now...
> 
> ----
> 
> Bye,
> Roland
>