[gnutls-dev] Re: Compiler warnings on 64bit archs

[Simon Josefsson]

Andreas Metzler <ametzler at downhill.at.eu.org> writes:

> After adding the missing AC_CHECK_SIZEOF(void *), this indeed works.
>
> So how would you like to have the 19 [1] occurences of this issue
> fixed, is there a central header file GNUTLS_POINTER_TO_INT can be
> thrown into (besides gnutls.h)?
>
> thanks, cu andreas
> [1]
> in gnutls-20060628.tar.gz:
> gnutls_openssl.c:283: warning: cast to pointer from integer of different size
> gnutls_openssl.c:290: warning: cast to pointer from integer of different size
> gnutls_openssl.c:301: warning: cast to pointer from integer of different size
> gnutls_openssl.c:880: warning: cast from pointer to integer of different size
> gnutls_openssl.c:892: warning: cast to pointer from integer of different size

I've moved the macros to gnutls_int, and fixed the above warnings.

> serv.c:954: warning: cast to pointer from integer of different size
> cli.c:831: warning: cast to pointer from integer of different size
> psk.gaa:28: warning: assignment makes integer from pointer without a cast
> tls_test.c:270: warning: cast to pointer from integer of different size
> ex-cert-select.c:156: warning: cast to pointer from integer of different size
> ex-client1.c:54: warning: cast to pointer from integer of different size
> ex-client2.c:62: warning: cast to pointer from integer of different size
> ex-client-resume.c:61: warning: cast to pointer from integer of different size
> ex-serv1.c:134: warning: cast to pointer from integer of different size
> ex-serv-anon.c:119: warning: cast to pointer from integer of different size
> ex-serv-export.c:179: warning: cast to pointer from integer of different size
> ex-serv-pgp.c:138: warning: cast to pointer from integer of different size
> ex-client-srp.c:72: warning: cast to pointer from integer of different size
> ex-serv-srp.c:123: warning: cast to pointer from integer of different size

Those are not in the library, and from what I understand, the cast
isn't actually invalid -- the behaviour is what we intend and well
defined on all platforms we care about, isn't it?

The right solution is probably to change the APIs so this situation
never arise.  Without more insight to what harm (if any?) the warning
causes, changing the API doesn't seem warranted.

/Simon