(Illustration by Gaich Muramatsu)
Well, the size of long shouldn't change. Only the size of pointers and how long long is implemented. I don't know about netbsd, but virtually every entity I'm aware of (Sun, HP, Linux) a long is 32 bits no matter how it's compiled. Otherwise, bloody everything will break. I think that a long on Alpha is 64 bits, but that's the exception, because it was never anything else on Alpha, but causes a mess of problems getting software to work on Alpha. So, at least for Linux, you shouldn't Well, the C spec doesn't say how big things are. 64-bit longs are pretty rational. In The Beginning, short, int and pointers were 16 and long was 32. Then on vaxes short stayed 16 and ILP32. On NetBSD/sparc64, long is 64 bits. 24 ~ > cat long.c #include <stdio.h> #include <sys/types.h> main() { printf("char %d, short %d int %d long %d long long %d void* %d\n", sizeof(char), sizeof(short), sizeof(int), sizeof(long), sizeof(long long), sizeof(void *)); printf("int8_t %d, int16_t %d int32_t %d int_64t %d\n", sizeof(int8_t), sizeof(int16_t), sizeof(int32_t), sizeof(int64_t)); } 25 ~ > ./long char 1, short 2 int 4 long 8 long long 8 void* 8 int8_t 1, int16_t 2 int32_t 4 int_64t 8 I thought 64-bit longs were normal, and most machines were LP64, but that alpha was ILP64. But you are right about trouble - there is a lot of code out there that assumes fixed sizes for built-in types. This is simply wrong, as C makes no such guarantees. Program should use u_int32_t etc. when they mean 32 bits, e.g. for on-the-wire quantities. I think that the latest versions of lint have modes that can check your code for possible places they will break if compiled for 64 bit use. And gcc -Wall is pretty thorough. This and lint will catch [int] = [void*] errors, but not using long for a network data structure where int32_t should have been used. Such code will interop fine between 64-bit machines, just not with the 32-bit machines out there. Since I've almost completed my port of coda to 2.11BSD (running on a PDP-11/73 - you really need separate I/D to squeeze it in), the 64-bit changes shouldn't be too hard. -- Greg Troxel <gdt_at_ir.bbn.com>Received on 2004-02-13 10:01:35