64 bit coding
rra at stanford.edu
Mon Apr 23 12:18:09 UTC 2001
Dan Foster <dsf at gblx.net> writes:
> 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
I think that if a compiler is warning about this sort of thing, there's
something wrong with the compiler. What is it complaining about, that
you're assigning a smaller data type to a larger data type? That's
> 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:
Huh? What does an int have to do with anything? That's assigning a char
pointer to a char pointer.
> "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.
I can't read this error message; it seems to be complaining about:
fgets(t, F->sbuf - strlen (F->buf), F->f);
but I don't know what it thinks is wrong with that.
> Only thing I can think of is some kind of conditional platform specific
> typedef'ing and use that, as ugly as that sounds.
That aboslutely shouldn't be necessary.
> 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 *).
INN shouldn't be making any assumptions like that.
I actually doubt that INN *is* making many assumptions like that, as INN
has worked fine on Tru64 for quite some time. I think you've got an
overactive compiler that's jumping at shadows, from the examples you've
given so far. But I'd be happy to see more specific details....
Russ Allbery (rra at stanford.edu) <http://www.eyrie.org/~eagle/>
More information about the inn-workers