appro> > My thought about that one was that BIO_ctrl would be declared
appro> > and defined to take a 'sin_of_ansification *'
appro> ^ you vote for #4, no star here.
Oops :-).
appro> > as argument instead of a
appro> > 'void *' (a non-anonymous variant 4).
appro> But it breaks *source* code compatibility and old users gonna
appro> get (really) frustrated.
That is true, but on the other hand, there have been many discussions
that seem to point to a need to break source compatibility. That or
doing a triple bendover at some point... And as far as I understand,
source compatibility has already been broken.
Here's another Decision for us: clean up and break source
compatibility on some points or work really hard at maintaining source
compatibility and building something that has potential of being quite
messy.
appro> > This would still be binary
appro> > compatible (as you noted), but would force new users to use a more
appro> > type-safe approach to the control functions. Also, in that case, new
appro> > ctl codes would not be required.
appro> Is a new code a problem?
Yes, in a way: it adds to the confusion. Imagine having to answer the
question "There are two ways to do exactly the same thing. Why?
Which one is the prefered way?" with something other than "hysterical
raisins" (eh, "historical reasons"...). There *is* the question of
maintainability, and I sometimes really wonder where we're heading
with that in mind.
appro> P.S. In reply to previous message.
appro> > Why have it different for o_names.c?
appro> It's uses private interface routines and #4 might be the appropriate
appro> option. Well, "private" means "not likely used by an average OpenSSL
appro> developer."
I've never trusted that kind of assumption. Especially with the
current state of documentation :-).
--
Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken \ S-161 43 BROMMA \ T: +46-8-26 52 47
\ SWEDEN \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED]
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]
