[gnutls-dev] size_t, int and 64 bit machines
simon at josefsson.org
Wed Mar 21 17:54:33 CET 2007
Deanna Phillips <deanna at sdf.lonestar.org> writes:
> Simon Josefsson writes:
>>> typedef struct
>>> unsigned char *data;
>>> - unsigned int size;
>>> + size_t size;
>>> } gnutls_datum_t;
>> I am aware of this one, but the problem is: it is part of gnutls.h and
>> thus part of the external API. This is really problematic to change,
>> since it won't be backwards compatible.
> Oops. That changes everything, doesn't it. :-)
>> However, can we get away by considering that GnuTLS doesn't
>> work at all on platforms with 8-byte size_t and just make the
>> change? We have already some supported 64-bit platforms,
>> e.g. amd64 and ia64, but do they have 8-byte size_t? I doubt
>> this is a reasonable way forward...
> On OpenBSD, all 64-bit hardware platforms have an 8-byte size_t.
> I just checked NetBSD/alpha, and it's the same there. I don't
> know about Linux or any other systems. Now, the testsuite does
> pass on two of those, OpenBSD/amd64 and OpenBSD/alpha, but fails
> on OpenBSD/sparc64.
If they have 8-byte size_t, there are probably hidden problems, like
those in your patch.
> If supported means compiles and runs, then I guess things are
> ok. Often, when some error like this is found on OpenBSD, it's
> because one of the memory protection features caught it. Since
> sparc64 is the only 64-bit platform that actually produced
> incorrect results, I'm thinking about what's unique there: 1)
> strict alignment and 2) StackGhost. It's a bit over my head to
> say for sure, but I'd be happy to perform any tests you might
> want to try.
I think that if GNU/Linux on amd64 or ia64 have size_t==8, then we
cannot use this escape-route, we'll have to solve this properly. I
think GnuTLS is used a lot on many amd64/ia64 systems.
This approach was probably just wishful thinking, we need to solve
this properly. The question is how.
More information about the Gnutls-devel