Re: Code changes for glib to enhance 64-bit operation

[Tim Janik <timj gtk org>]

On Mon, 14 May 2001, Mark Murnane wrote:

> The matter of GPOINTER_TO[U]INT and friends is quite important.  Despite
> the intention of these macros, they can be used to stuff a pointer into
> an int.  Perhaps we could compromise on a GPOINTER_TO_SIZE macro
> instead?  Owen suggested this and it might keep everyone happy.  

i'm not sure every platform guarrantees pointer->size->pointer without
lossage, owen?

> The loss of resolution in a 64-bit pointer potentially could be an
> issue, even if its unlikely.  The memory mapping for an executable,
> created at compile time, could lead to an application accessing the
> address where the bottom 32-bits are identical.  

sure, for taht i suggested OR-ing in the higher 32 bits when
creating a hash value for a pointer.

> The cast in gutils.c:g_get_any_init() for the sysconf return makes
> things clearer.  Changing to a long just necessitates a cast a few lines
> later when the buffer size is passed as a parameter to getpwuid_r()
> which expects an integer.

you don't need a cast there either, compilers handle promotion of longs
to ints automatically.

> The change value_flags_enum_lcopy_value() in gobject/genums.c you have a
> point with.  What is the effect though of losing data from the long
> value copied in to that location at the end of the function though?

basically none, since you can't set a flags/enum value to something >2^32
in the first place. basically we only support flags and enums with 32 bits.

> 
> Anyway, that's enough to be going on with for now!
> 
> Thanks,
> 
> Mark
> 

---
ciaoTJ