64 bit coding
dsf at gblx.net
Mon Apr 23 11:55:47 UTC 2001
I put the 16 Feb code base through a 64 bit build for the first time. That
was very educational... 616 compiler warnings related to 64 bit handling. :-)
I would say that probably 80% of it is due to the varargs stuff.
(va_start, VA_NEXT, etc.)
Such as this code body; each reference of va_arg with the int data type
results in a compiler warning:
if (cflags == DP_C_SHORT)
value = va_arg (args, short int);
else if (cflags == DP_C_LONG)
value = va_arg (args, long int);
value = va_arg (args, int);
It's because all of these are not 64 bit wide, and the compiler is converting
the various sized int datatypes internally to be 64 bits wide.
Then there are assumptions that char will always be an int, such as:
char *result, *p;
p = result;
results in this complaint from the compiler:
"conffile.c", line 60.19: 1506-743 (I) 64-bit portability: possible change of
result through conversion of int type into long type.
"conffile.c", line 60.26: 1506-742 (I) 64-bit portability: possible loss of
digits through conversion of long type into int type.
Compiler is VisualAge C/C++ 5.0 under AIX 4.3.3 with the -q64 and -qwarn64
compiler options enabled in Makefile.global.
Why am I interested in seeing INN be 64 bit clean? Because with the way
newsfeeds are growing, means that eventually we'll see very large databases,
CNFS files, memory space, etc.
I'm not too experienced with the portability issues for 32->64 bit coding,
especially since this may differ on a per-platform level. Suggestions welcome.
Only thing I can think of is some kind of conditional platform specific
typedef'ing and use that, as ugly as that sounds.
With AIX's compiler in 64 bit mode, it converts all long and pointers to
be 64 bit wide. This breaks any code that assumes sizeof(int) == sizeof(long)
== sizeof(void *).
More information about the inn-workers