Re: Prevalence of Compilers for Which Integer'Size < 32?

[dewar@cs.nyu.edu (Robert Dewar)]

Dave Marshall says

"My specific question revolves around something such as this example
that you'll find in a lot of time-handling packages.

type Seconds_In_A_Day is range 0 .. 86_400;

This is going to work fine for compilers for which Integer'Size is 32,
but it will fail for compilers for which Integer'Size = 16.  Of
course, this is because the above statement is equivalent to

type some_anonymous_integer_type is new Integer;
subtype Seconds_In_A_Day is some_anonymous_integer_type range 0 ..86400;"


This is technically incorrect. There is no requirement that in the above
Seconds_In_A_Day be derived from Integer, it can be derived from any
available predefined type in Standard. Yes, in theory you can imagine
a compiler that would not accept this, but in practice absolutely
every compiler wlil accept the above declaration. The 16-bit PC
compilers where integer is 16 bits (from both RR and ALsys) both
provided a 32-bit long_integer suitable for the above derivation.
I believe the most restrictive compiler available is the Intermetrics
Patriot-2 compiler, where the largest integer size is 24 bits, but (a)
I might be wrong on this, (b) I doubt you are using this compiler :-)
and (c) anyway 86_400 fits in 24 bits.

As to never using type Integer, you often see this advice, but like
most absolute rules, if you follow this rule absolutely, you will be
in trouble. It would mean that you could not use the built in type
String, and consequently could not use any library packages depending
on string (including unbounded_strings, bounded_strings, all the I/O etc).

In addition, you could not use the exponentiation operation on real
values.

So in practice the rule is not to use Integer where it is easily avoided,
but use it where necessary for predefined stuff.