[gnutls-dev] size_t, int and 64 bit machines

[Simon Josefsson]

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.  :-)

Alas, yes.

>> 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.

/Simon