On Thu, Oct 13, 2005 at 01:41:56PM +0200, Peter Sylvester wrote: > In ssl/ssl_lib.c there is a lot of functionality of get/set implemented > through a SSL_ctrl or SSL_CTX_ctrl, but some are implemented > directly as functions. > > There may be some logic behind that but I am not sure which one. > One thing seems to be that the get function which need a pointer > are implemented directly whilst some functions that return integers > are in a ctrl. > > There is for example the GET/SET READ_AHEAD in a ctrl returning > an int, but all all set/get_verify_mode etc are all as independant > functions, and, well, there is an void SSL_set_read_ahead > which duplicates the functionality. > > It seems that there had been an effort to move accessors to > the SSL_ctrl and SSL_CTX_ctrl, since in older versions the > SSL_ctrl was basically empty and just an interface to the > method dependant code. There is also the GET_SESSION_REUSED > which is common to the v2 and v3, thus could be moved to > ssl_lib.c > > It may be that some stuff is left there to maintain compatibility, > i.e., the explicit functions like SSL_set_read_ahead > > It would be nice to have a kind roadmap somewhere (which may > already exist) to indicate whether the xxx_ctrl are 'the future' > or not, and if yes, how to provide the 'get' functions for structures > like (SSL_get_ctx).
I don't think there is a clear policy on this ... An advantage of specific functions is that you can define appropriate prototypes. Not everything will fit into the SSL_ctrl API, and if it does, you always have the 'long' and 'void *' arguments even if 'int' or a specific pointer may be more appropriate. An advantage of the SSL_ctrl (and SSL_CTX_ctrl) approach is that these are automatically method-dependent, i.e. you can put things into ssl3_ctrl() that don't apply to SSL 2.0. Often it may make sense to define a specific function with appropriate prototype, but implement it through SSL_ctrl() so that its action is method-dependent. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
