64 bit coding

[Russ Allbery]

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);
>         else
>           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.

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
allowed.

> 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/>