Andy Polyakov <[EMAIL PROTECTED]>:
>> 5. Have the caller tuck the parameter in a union that will represent
>> function pointers as well as other pointers, and pass that union
>> by reference.
>> Choices 4 and 5 assumes that the parameter in question will be
>> prototyped and used like this:
>>
>> int foo(..., union fn_n_data parg, ...)
>> {
>> /* ... */
>> int (*fptr)() = (int (*)())(parg.fn);
>> /* ... */
>> }
> Why assign? parg.fn() (#4) and parg->fn() (#5) suffice and are perfectly
> readable/debuggable, aren't they?
In the above example, yes; but not when it's really
int (*fptr)(int, char) = (int (*)())(parg.fn);
or even
long (*fptr)(int, char) = (int (*)())(parg.fn);
> My vote is #5 for crypto/mem_dbg.c, crypto/bio/bss_conn.c, ssl/s3_lib.c
> with new calls and separate ctl codes for binary compatibility [...]
I don't think it's worth to blow up the code that much to get binary
compatibility (but by adding a couple of lines of these "switch"
statements we can generate error messages that tell everyone to change
their programs -- then, a version or two later, we can get rid of this
extra code). It's easy to provide source code compatibility except
when SSL_ctrl and the other similar functions are called directly --
to catch these cases we should slightly rename the SSL_ctrl command
codes to cause compiler errors for programs that call it anyway.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
