David Schwartz wrote:
>> 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.

>
> Length is not the issue. There is no rule that says that two types must be
> passed the same way just because they're the same length. For example, some
> platforms may pass a 64-bit floating point number in a floating point
> register but pass a 64-bit integer in an integer register.
>
> All you can do is assume that it will work because it has always worked,
> until it stops working.
>
>> 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.

>
> If they are not the same length, it is not likely to work. That doesn't mean
> it's legal if they are the same length.
>
>> 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.

>
> The issue is not size, it's type.
>
>> 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.

>
> You are correct, but that's not the issue. The issue is this simple -- if
> you are going to call a function whose types you don't know (through a
> prototype), you must cast each type you pass to the type the function
> expects. End of story. OpenSSL does not do this. This is not valid C whether
> or not the type sizes are the same.
>
>> 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.

>
> Can you cite anything in the C standard that says this is allowed? As I
> understand it, you must pass a function precisely the types it expects, or
> use a prototype to force the compiler to cast them. Either way, the exact
> type must be known where the call is compiled.


It appears to me, then, that the consequence of this is that we can't
have type-safety and generic functions. This strikes me as a huge pain
in the ass. Surely there's some way around it?

--
http://www.apache-ssl.org/ben.html http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org