This is a multipart message in MIME format.
--=_alternative 00766EE34A257220_=
Content-Type: text/plain; charset="US-ASCII"

"
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"
Sent by: owner-openssl-dev@openssl.org
09/11/2006 06:47 AM
Please respond to
openssl-dev


To

cc

Subject
RE: OpenSSL breaks with gcc 4.2







> 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=NULL;
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 majordomo@openssl.org


--=_alternative 00766EE34A257220_=
Content-Type: text/html; charset="US-ASCII"



"

           
     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"
<davids@webmaster.com>


Sent by: owner-openssl-dev@openssl.org

09/11/2006 06:47 AM




Please respond to

openssl-dev









To

<openssl-dev@openssl.org>

cc



Subject

RE: OpenSSL breaks with gcc
4.2
















> 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=NULL;

       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              
            majordomo@openssl.org




--=_alternative 00766EE34A257220_=--
__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org