64 bit ints

[Richard A. O'Keefe]

In article <8803 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>In article <225800084 at uxe.cso.uiuc.edu> mcdonald at uxe.cso.uiuc.edu writes:
>-Then allow the user to specify, either ... by command line switches ...
>-whatever combination of shorts, ints and longs he wants

>This is unworkable.  The application code has to interface with the
>C library and other libraries.  It is unrealistic to expect there to
>be umpteen variants of each library to support all the permutations
>of data sizes.

It may be unworkable, but there are a lot of Fortran compilers that do it.
(UNIX "f77" compilers use the flags "-i2" (int=short) "-i4" (int=long).)

What you do is introduce some implementation-specific types:
	__s8	__s16	__s32	__s64	(signed)
	__u8	__u16	__u32	__u64	(unsigned)
	8-bit	16-bit	32-bit	64-bit
Then the library headers include prototypes using the implementation-
specific types.  The *printf family can be handled by ensuring that
integral arguments passed to that function are widened to __s8 or __u8
or whatever.  The *scanf family is tricky, but I can think of several
solutions.

While it would be workable, it probably wouldn't be a good idea.
Probably the best thing to do would be to pick an "efficient" value for
'int', and offer two system-dependent macros _SIGNED(N), _UNSIGNED(N)
expanding to the smallest integral types capable of holding N-bit
integers; the expansions needn't be available any other way.  _SIGNED(N)
is similar to a current proposal for Fortran 8X, and the concept is
sufficiently system-independent that other compiler-writers might pick
it up.