[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Deanna Phillips
Subject: Re: [gnutls-dev] size_t, int and 64 bit machines
Date: Wed, 21 Mar 2007 15:57:25 +0000
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (berkeley-unix)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]