"
Please tell me how the compiler knows what type 'x' should be passed as. If
you pass a pointer to a function as 'd2i' whose first type is not defined as
a 'char **', you get undefined behavior -- how can the compiler possibly use
the correct type's passing rules when it thinks the function takes a 'char
**' and it actuall takes an 'X509 **'.
"
x is still just a pointer to data - so it's the same length in any case, all pointers to lvalues are the same length in C. The only issue there is whether it's aligned correctly - that's the programmers problem.
Mixing something like char *(*d2i)(), and char ** IS problematic, since those aren't guaranteed to be the same length but as far as I can remember OpenSSL doesn't do that.
ret=d2i(x,&p,len);
d2i is a function (prototype is unknown)
but I've been told x is a pointer, &p is a pointer, len is long. There's nothing indeterminate about the size of any of those.
C isn't a strongly typed language - there's no language requirement for an accurate function prototype or that the types of the arguments be correct - only that the size of them is correct.
C is not the same language as C++, this instance should work with a C compiler - whether or not the compiler is passing the arguments via the stack or in registers.
Peter
Peter Waltenberg
| "David Schwartz"
<[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED] 09/11/2006 06:47 AM
|
|
> But it gets cast back to the correct type before it is called. These
> casts are done the way they are to get type-safety. Removing that option
> strikes me as a bad thing.
It does not. Look closely at how these functions work:
char *PEM_ASN1_read_bio(char *(*d2i)(), const char *name, BIO *bp, char **x,
pem_password_cb *cb, void *u)
{
unsigned char *p=NULL,*data=""> long len;
char *ret=NULL;
if (!PEM_bytes_read_bio(&data, &len, NULL, name, bp, cb, u))
return NULL;
p = data;
ret=d2i(x,&p,len);
if (ret == NULL)
PEMerr(PEM_F_PEM_ASN1_READ_BIO,ERR_R_ASN1_LIB);
OPENSSL_free(data);
return(ret);
}
Please tell me how the compiler knows what type 'x' should be passed as. If
you pass a pointer to a function as 'd2i' whose first type is not defined as
a 'char **', you get undefined behavior -- how can the compiler possibly use
the correct type's passing rules when it thinks the function takes a 'char
**' and it actuall takes an 'X509 **'.
OpenSSL does *not* cast the function back to the correct (exact) type
before it calls it. Neither does it cast the function's parameters to the
right type. As a result, the code only works by luck. In the case of
'PEM_read_X509', it works if 'char **' and 'X509 **' happen to have the same
function parameter rules. Nothing requires this to be the case.
There is now way the compiler can know how to properly pass 'x' to 'd2i'. A
function cannot call another function whose parameter types it does not know
and can vary.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
