From: fouts@bozeman.hpl.hp.com (Martin Fouts)
Subject: Re: NO NUMBERS! (or even SHORT INTS!)
Date: Tue, 29 Sep 1992 17:34:33 GMT
Reply-To: fouts@hpl.hp.com
Organization: Hewlett-Packard Labs

In article <1992Sep29.043522.4803@linus.mitre.org>,
crawford@boole.mitre.org (Randy Crawford) writes: 
|> In article <1992Sep28.003421.1246@RedBrick.COM> jfr@RedBrick.COM () writes:
|> [...]
|> >In a related conversation, someone mentioned that many organizations have
|> >coding standards that let them redefine the size of ints to keep this
|> >from happening.  For instance use int1, int2 and int4 as typedefs and you 
|> >can make them whatever you want.  This is where the thought struck me that
|> >makes me curious to get other peoples' opinion on.  Why would you EVER
|> >use NUMBERS in a program.  
|> 
|> [...] Because most PLs don't specify IN or OUT variables
|> using subranges, the programmer cannot know how large a data
|> structure is needed to hold return values.  As such, the data type
|> MUST match that specified by the function call prototype (if it
|> exists).  Because dissimilar architectures often have different 
|> names for 2 byte ints, you will find the function prototypes differing from
|> machine to machine.  The only way I know to produce code which is portable 
|> across their C libraries is to describe argument variables as being
|> of sizes  which match each architecture's prototypes with a minimum
|> of re-editing.  How better to do that than embed the integer size
|> in the type name (INT2, INT4, UINT2, UINT4, ...)?
|> 

They use to do this in Fortran.  (Actually, they still do, but I'm
trying hard to forget that dark part of my life ;-)  The problem is
the assumption that vendor x will make an exact substitution of types
from vendor y, for example, for every function that vendor x specifies
INT2 for, vendor y will specify INT4, but the choice is made on a
function by function basis.

Careful usage is to identify the return type of each function as
'function_return_t', and to use that type appropriately,
including explict casts, and to force the vendor to provide a header
including the correct typedef for function_return_t.  Of course,
if a lot of functions are returning a similar thing (ie, they all
return kernel_error_t) then they all get to use the same return type.

Complete usage is for you to do the same thing.  You need to figure
out 'classes' that each of your variables belong to and to generate
typedef type names for each 'class' and then to always declare
variables to be of the correct 'class.'  (This 'class' has nothing to
do with OO programming.)

Unfortunately, after you've done all of this, you have a program in
which you can easily identify the integer storage size requirements in
all cases -- except 2:  Constants, and scanf/printf arguments.

This whole thing is going to get even uglier when you can find usable
64 bit integers and two different sizes of pointers on more machines
than just Crays.  (To see the two sizes of poitners problems, program
a pc in pc-C...)

Marty


|> --
|> Randy
|> crawford@mitre.org
|> -- 
|> 
|> | Randy Crawford        crawford@mitre.org        The MITRE Corporation
|> |                                                 7525 Colshire Dr., MS Z421
|> | N=1 -> P=NP           703 883-7940              McLean, VA  22102

-- 
Martin Fouts                  |  M/S 1U-14
Member of Technical Staff     |  HP Laboratories
EMAIL:  fouts@hpl.hp.com      !  MAIL:  P.O. Box 10490
PHONE:  (415) 857-2971        |  SHIP:  1501 Page Mill Road
  FAX:  (415) 857-8526        |  Palo Alto, CA 94304-1126

novae erratae!
Xref: sparky comp.programming:2766 comp.lang.c:14504 comp.lang.pascal:5805 comp.lang.objective-c:576