[gnutls-devel] Casting from int to (void *)

[Tim Ruehsen]

Am Thursday 07 February 2013 schrieb Stef Walter:
> On 02/07/2013 07:06 PM, Nikos Mavrogiannopoulos wrote:
> > On 02/07/2013 03:10 PM, Jaak Ristioja wrote:
> >> The current solution probably works for most x86 setups, but not for
> >> all. The compiler warning is completely reasonable, as it points out
> >> something which might not work properly on some platforms.
> >> I suspect this behavior can't be corrected without breaking the ABI/API.
> >> I think stuff with actual (void *) pointers still works if the
> >> respective callbacks are properly set.
> > 
> > Hello,
> > 
> >  I by change to the ABI you mean adding a new function, that's not a
> > 
> > high cost.
> > 
> > However, my main concern is whether there is an actual system where the
> > current approach causes a problem in order to justify any action (at
> > least from my part, if you submit a patch for that, that's another
> > story).
> 
> FWIW, Glib has has macros for putting ints into pointers, and taking
> them back out:
> 
> GUINT_TO_POINTER
> GPOINTER_TO_UINT
> GINT_TO_POINTER
> GPOINTER_TO_INT
> 
> I mention this because I believe the general consensus is that there is
> no relevant platform for which you can't store 32-bits of integer in a
> pointer.

IMHO, the glib is still pretty Gnome centric. That would mean "relevant 
platform" = "Desktop platform", well a bit simplified.

BTW, the mentioned macros are just simple chains of casts that are made to 
silence the compiler. You can do that  'void *p = (void *)(ssize_t)i' and back 
with int i = (int)(ssize_t)p; 
But this is not elegant and looks like a hack, if you use macros or not (well,  
it IS a hack).

There might be some (obscure, embedded ?) platforms where this doesn't work. 
E.g. having 16-bit pointers and/or platforms with non-flat memory models where 
NULL is not 0. Or function pointers having a different size than memory/void 
pointers. Are these platforms relevant to GnuTLS !?

As long as no one comes along having real (not just theoretical) serious 
problems, the only reason to change anything is of 'code elegance' and to calm 
down 'security experts' (I read this C article of securecoding.cert.org - it 
is correct in general, but doesn't fit for the special case of 
gnutls_transport_set/get_ptr).

But then, 'code elegance' might be an important thing (at least to me).
And providing a ..._set/get_int() (I personally wouldn't call it _berkeley) 
wouldn't really hurt, would it.

Regards, Tim