Re: Code changes for glib to enhance 64-bit operation
- From: Tim Janik <timj gtk org>
- To: Mark Murnane <Mark Murnane Sun COM>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>, Michael Myburgh Sun COM
- Subject: Re: Code changes for glib to enhance 64-bit operation
- Date: Tue, 22 May 2001 01:27:38 +0200 (CEST)
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
> 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!
] [Thread Prev