On Thu, 5 Sep 2002, Thiemo Seufer wrote:
> > at the source level, you have autoconf or <stdint.h> as you can't
> > arbitrarily assume any type sizes for any portable code.
>
> Not everyone uses autoconf, and if you call "long long" a recent
> addition then the use of <stdint.h> isn't safe, too.
That is not an excuse, sorry. You need not to use autoconf or <stdint.h>
if you don't want to -- you may use a different tool or simply group all
tweakable settings in config.h and ask a user to edit it manually like
autors of old programs did.
> Using the same data types allows at least to choose the appropriate
> typedefs without caring about the underlying OS.
It doesn't. It is unsafe to assume it in general and it's even more
unsafe for MIPS where we have at least three C models and you do not know
in advance which one will a person doing a build choose.
> > What programmer's POV? Does a programmer write a program for MIPS? No,
> > unless he writes a kernel or a libc. A normal programmer just codes a
> > program in C for a *nix-type system and if he wants any portability, he
> > needs to follow universal guidelines.
>
> World isn't as perfect as you claim. And for non-broken code it's
> nearly irrelevant if the 64 bit integer type is called "long" or
> "long long".
World isn't perfect, but it would be beneficial if at least we tried to
keep it as good as we can.
> About 128 bit integers: Most OS'es use "long long" already for
> 64 bit integers, which means there will be something like
> "quad long" for 128 bit integers (if these are needed).
We'll see, but I wouldn't bet on it. Personally, I'd rather see "long
long" to be a double-precision (not necessarily 128-bit) type universally.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
|