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 +
