nmav at gnutls.org
Mon Apr 14 06:11:15 CEST 2008
Simon Josefsson wrote:
> Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:
>> About the new crypto engine I think it should be included as is in the
>> new release. It is not tested but API-wise I don't expect changes. I
>> could add the mpi interface after the release in the development
> Ok, I looked over the API, and I think we need to do at least #1/#2
> before we can release it:
I'm still working on it so let's disable it for the release. I'll put
today an #if 0 on this code.
> I think that avoiding struct's in the public API would be a good idea
> (struct alignment always seem to cause problems on weirder platforms),
> so how about instead of doing something like this:
> do this instead:
> typedef int (*gnutls_rng_init_func)( void** ctx);
> typedef int (*gnutls_rng_rnd_func) ( void* ctx, gnutls_rnd_level_t level, void* data, int datasize);
> typedef void (*gnutls_rng_deinit_func)( void* ctx);
Although not using structures is better for the API, the whole crypto.c
will be inconsistent with some functions taking pointers to structures
as arguments and others functions. I don't like the idea so much.
> Use 'size_t' for buffer length variables instead of 'int'.
I'll do this.
> Couldn't we align the GNUTLS_RND_* symbols to match the libgcrypt
> values? In other words, change the order and values of the symbols.
> Not important, but might simplify libgcrypt mapping...
More information about the Gnutls-devel