derived types
Norman Diamond
ndiamond at watdaisy.UUCP
Tue Jan 22 06:39:42 AEST 1985
> /*
> one of the constraints not mentioned so far (or i missed it) is that
> sizeof(int) must be the same as sizeof(int *). the practice of defining
> derived types is an attempt to avoid machine dependency. however, why
> not say what we REALLY (yes, my tty has caps) mean: dispense with
> char, short, int, long, and use byte, word, long, and quad. my model
> is the vax, with sizes of 8, 16, 32, & 64 bits respectively. while
> this is somewhat ethnocentric, it pays homage to the fact that unix
> was developed on these two machines primarily. weird machines such
> as u1108 (b=9, w=18, l=36, q=72) and cdc6400 (b=6?, w=15, l=30, q=60)
> would have to adapt as best they can (they kinda have to now anyway).
> this unfortunately blows the correspondence between int & int *, but
> i suspect that the standard will have something more to say about
> ptr's than the opening sentence of this paragraph. (b=10 for cdc6400?)
> */
A lot of micros would have to adapt too. (Do they kinda have to now
anyway?)
It has been a long time since anyone suggested that a language could be
standardized in such a manner that for some machines, any implementation
is automatically non-standard.
Or there's another solution: every "primitive" entity can be stored in
the same size unit, the unit being large enough to hold any kind of
entity (double? in some languages, double complex?). The excess space
would of course be "intentionally left unused".
-- Norman Diamond
UUCP: {decvax|utzoo|ihnp4|allegra|clyde}!watmath!watdaisy!ndiamond
CSNET: ndiamond%watdaisy at waterloo.csnet
ARPA: ndiamond%watdaisy%waterloo.csnet at csnet-relay.arpa
"Opinions are those of the keyboard, and do not reflect on me or higher-ups."
More information about the Comp.lang.c
mailing list