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 <[EMAIL PROTECTED]>
