Re: a reminder about 64-bit machines

[Owen Taylor <otaylor redhat com>]

"Gareth Pearce" <tilps hotmail com> writes:

> >
> >
> >"Gareth Pearce" <tilps hotmail com> writes:
> >
> > > On the topic of 64bit cleanness, would maintainers like it if I logged
> > > a stack of bugs against compiler warnings of the type 'cast from
> > > pointer to integer of different size' and its reverse?  I havent ever
> > > actually seen this cause actual problems - but its definitely not
> > > clean.  In some cases fixing it might result in an api change (at
> > > least on 64bit machines).
> >
> >I don't see why ... usually, these warnigns just indicate
> >that an standard cast from void * to int needs to be switched
> >to use the G[U]INT_TO_POINTER() / GPOINTER_TO_[U]INT macros.
> >
> >It's very seldom that when you are storing an integer in a pointer
> >you actually want to store a 64-bit quanity.
> 
> umm, the problems which occur are when your doing pointer arithmatic
> and storing differences between pointers in integer temp variables
> (instead of ptr_diff_t).  Or storing pointers in integers.  Maybe all
> the cases in the code are just ints being stored in pointers, but I
> thought I had seen some that were not.

I don't think that will give you that particular warning
(The result of pointer arithmetic is an integral
type, not a pointer, so it's not a cast from a pointer to
an integer of a different size.) As far as I know, there
is no way to get GCC to warn about casts from size_t to
int when int is smaller ... and that's probably good
since there would be lots of false positives.

For 2.0, I actually went through and tried to make GLib work
with 64-bit quantities

 - Use size_t/ssize_t for string sizes / byte counts
 - Use long for counts of non-byte objects.

But in almost all places, 32 bits is perfectly fine.

Regards,
                                        Owen