Richard Levitte - VMS Whacker <[EMAIL PROTECTED]>:

> Let me see if I got it all.  So far, I've seen the following
> alternatives:
> 
>   1. ignore the problem (obviously not the right thing to do :-)).
>   2. take the parameter in question as we do today, but use a union so
>      the compiler will shut up (which is a fancy way of ignoring the
>      problem).
>   3. whenever the passed parameter is a function pointer, use double
>      indirection and assume the caller has really passed a reference
>      to a function pointer.
>   4. Have the caller tuck the parameter in a union that will represent
>      function pointers as well as other pointers, and pass that union
>      by value.
>   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.

> Actually, 4 and 5 are basically the same.

No, 5 is to 4 what (for function pointers) 3 is to 1.

> Choices 1 and 2 are really just as bad, they're designed to ignore the
> problem instead of dealing with it.
> 
> Choice 3 assumes that the parameter ni question will be prototyped
> and used like this:
> 
>       int foo (..., void *parg, ...)
>       {
>               /* ... */
>               int (*fptr)() = *(int (**)())parg;
>               /* ... */
>       }
> 
> It's a good way to deal with the problem in what could be perceived as
> a safe way, but for a detail: there's no way to see from the API that
> function pointers need to be handled differently than other pointers
> when passed down to the functino using them ("doall" and "ctrl"
> functions...), and the compiler will not give a hint.

It will give a hint!  Just don't use casts, and the compiler will
complain when you try to pass a function pointer directly.  Simarly,
the function using the function pointer can be written without casts
if it is using the pointer correctly; if it's incorrect, you need
casts to make the warning go away.

> And yes, there will be the problem of binary compatibility in all
> choices but 1 and 2...

Choice 4 should be binary compatible as well, because on platforms
where choice 1 and 2 work in practice both types of pointers
have the same length, so probably the union won't be any different.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to