On Tue, Jun 15, 1999 at 10:03:18AM +0200, Alessandro Vesely wrote:
> Bodo Moeller wrote:

>> [...]
>> #undef PEM_read_PrivateKey
>> EVP_PKEY *PEM_read_PrivateKey(FILE *fp,EVP_PKEY **x, pem_password_cb *cb)
>> {
>>     return PEM_read_PrivateKey_ex(fp, x, cb, NULL);
>> }

> two notes:
> 
> 1) on compilers that support inlining, defining the above function
> with *static* qualifiers in the include file would build the same
> executable, avoiding the additional define/undef coding.

Function definitions don't belong into exported header files; there is
no need at all to define the above as an inline function if we have a
macro of that effect.  The point in defining it as a function is to
produce object code that can be linked to programs which used the old
header files.

> 2) some compiler, specially on NT, like to call dynamically linked
> function with non-C calling conventions (because someone noticed
> that a few nanoseconds can be saved when it is the callee to free the
> stack, rather than the caller). This must be avoided, because the
> callback will end up being called with one more (NULL) parameter.

The callback function is not dynamically linked, it is passed as a
function pointer.  The functions that *take* such a function parameter
will be dynamically linked, but if we have two versions of them (a new
one with _ex suffix, and the old one with the same prototype that it
always had) there can be no problems of this kind.  However you are
right if "strange" calling conventions apply also to the callback
function itself (i.e. to the one which is passed as a function
pointer); but I don't think this is likely to be an actual problem,
given that the library currently relies on that calling functions
without having a declaration of the argument list (which, I think, is
equivalent to calling a function with variable parameters, although
I'm not really sure of this) works as expected.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to