In message <[EMAIL PROTECTED]> on Mon, 19 Aug
2002 15:08:03 +0200 (MEST), Rainer Orth <[EMAIL PROTECTED]> said:
ro> Richard Levitte - VMS Whacker writes:
ro>
ro> > You should take a closer look at 0.9.7 (currently in beta), where a
ro> > some of the stricter type handling has already been applied.
ro>
ro> I think I had a quick look at the CVS mainline, and the problems were still
ro> present there. Unless there are patches in the 0.9.7 branch that haven't
ro> made it into mainline yet, it should apply equally to both.
Have you looked at lhash.h, and the DECLARE_LHASH*/IMPLEMENT_LHASH*
macros? That's how we have started to solve the type problems. Yes,
the generated functions contain some internal casting, but in such a
way that they don't affect the code that use them, and thereby perform
type safety in an acceptable manner.
ro> We have
ro>
ro> int i2d_ASN1_IA5STRING(ASN1_IA5STRING *,unsigned char **);
ro> and
ro> int i2d_ASN1_BIT_STRING(ASN1_BIT_STRING *,unsigned char **);
You haven't looked very much at the mainline, have you? Those
declarations do not exist any more in the 0.9.7 and 0.9.8-dev
development lines. As a matter of fact, the ASN.1 parser/generator
have been rewritten more or less entirely. They use declaration and
implementation macros much like the lhash ones I mentioned above.
They are a little bit more complex, and found in crypto/asn1/asn1t.h.
ro> The situation is similar with the env_md_st function pointer members:
ro> e.g. the init function takes either an SHA_CTX * or MD5_CTX * or whatever.
ro> Unless one wants to change all those functions to take a void * as first
ro> arg (and loose type safety in all direct uses), the casts seem necessary
ro> (and unavoidable) to me.
Again, have you actually looked at the main line? The EVP_MD_CTX
structure has changed quite a bit, and instead of having a union of
different algorithm-specific values, it now contains a void* called
md_data. If you then look at the EVP_MD functions, you'll see that
they all take a EVP_MD_CTX*. If you look at the code, say m_sha1.c,
you'll see how it's handled, with type safety and NO casts.
ro> > We will probably not apply your change to the 0.9.6 line of
ro> > development, because it's a rather big change, and we try to avoid
ro> > that within the same line of development (for now, 0.9.x is a line of
ro> > development, so 0.9.7 is a different one, as is 0.9.8 (in development
ro> > right now, and where most if the bleeding edge hacking is done)). We
ro> > will definitely take a closer look at your patch for 0.9.7 and 0.9.8.
ro>
ro> I can probably rework the patch for either the 0.9.7 or 0.9.8 lines,
ro> whatever is more convenient for you.
I trust it will be a bit smaller than your current patch :-).
--
Richard Levitte \ Spannv�gen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47
\ SWEDEN \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Unsolicited commercial email is subject to an archival fee of $400.
See <http://www.stacken.kth.se/~levitte/mail/> for more info.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
