function pointer casting

hello all.

i am trying to get rid of some warnings and do "the right thing".
although in this particular case, i am not sure what the right thing
is.

the code:

typedef struct
{
void *ctx;
void (*init)(void *);
void (*update)(void *, const void *, unsigned long);
void (*final)(unsigned char *, void *);
int mdlen;
char *name;
} digest_t;

MD2_CTX md2ctx;
MD4_CTX md4ctx;
MD5_CTX md5ctx;
SHA_CTX shactx;
RIPEMD160_CTX rmdctx;

digest_t dig[] =
{
{ &md2ctx, MD2_Init, MD2_Update, MD2_Final,
MD2_DIGEST_LENGTH, "MD2" },
{ &md4ctx, MD4_Init, MD4_Update, MD4_Final,
MD4_DIGEST_LENGTH, "MD4" },
{ &md5ctx, MD5_Init, MD5_Update, MD5_Final,
MD5_DIGEST_LENGTH, "MD5" },
{ &shactx, SHA_Init, SHA_Update, SHA_Final,
SHA_DIGEST_LENGTH, "SHA" },
{ &shactx, SHA1_Init, SHA1_Update, SHA1_Final,
SHA_DIGEST_LENGTH, "SHA1" },
{ &rmdctx, RIPEMD160_Init, RIPEMD160_Update, RIPEMD160_Final,
RIPEMD160_DIGEST_LENGTH, "RIPEMD160" }
};

this code will yield a "warning: initialization from incompatible
pointer type", on every Init, Update, and Final function in dig[].
these functions are all in the format:

void MD5_Init(MD5_CTX *c);
void MD5_Update(MD5_CTX *c, const void *data, unsigned long len);
void MD5_Final(unsigned char *md, MD5_CTX *c);

with different types for the context. short of writing a wrapper
function for each of these (or one smart wrapper function for them
all), is there a safe solution to fix these assignments? while i'm at
it, please post other corrections are you see fit to call them.

thanks,
joe

re: function pointer casting

On 30 Apr 2004 21:17:25 -0700, joe_bruin@hotmail.com (joe bruin)
wrote:
[color=blue]
>hello all.
>
>i am trying to get rid of some warnings and do "the right thing".
>although in this particular case, i am not sure what the right thing
>is.
>
>the code:
>
>typedef struct
>{
> void *ctx;
> void (*init)(void *);[/color]

Here you say the second member of the struct is a function pointer
whose argument is void*.
[color=blue]
> void (*update)(void *, const void *, unsigned long);
> void (*final)(unsigned char *, void *);
> int mdlen;
> char *name;
>} digest_t;
>
>MD2_CTX md2ctx;
>MD4_CTX md4ctx;
>MD5_CTX md5ctx;
>SHA_CTX shactx;
>RIPEMD160_CTX rmdctx;
>
>digest_t dig[] =
>{
> { &md2ctx, MD2_Init, MD2_Update, MD2_Final,
> MD2_DIGEST_LENGTH, "MD2" },
> { &md4ctx, MD4_Init, MD4_Update, MD4_Final,
> MD4_DIGEST_LENGTH, "MD4" },
> { &md5ctx, MD5_Init, MD5_Update, MD5_Final,
> MD5_DIGEST_LENGTH, "MD5" },[/color]

Here you initialize an instance of the struct and the second member is
initialized to the address of MD5_Init.
[color=blue]
> { &shactx, SHA_Init, SHA_Update, SHA_Final,
> SHA_DIGEST_LENGTH, "SHA" },
> { &shactx, SHA1_Init, SHA1_Update, SHA1_Final,
> SHA_DIGEST_LENGTH, "SHA1" },
> { &rmdctx, RIPEMD160_Init, RIPEMD160_Update, RIPEMD160_Final,
> RIPEMD160_DIGEST_LENGTH, "RIPEMD160" }
>};
>
>this code will yield a "warning: initialization from incompatible
>pointer type", on every Init, Update, and Final function in dig[].
>these functions are all in the format:
>
>void MD5_Init(MD5_CTX *c);[/color]

But the function MD5_Init actually takes a pointer to MD5_CTX which
apparently is not the same as pointer to void.

When calling a function that expects a void*, you can pass any kind of
object pointer you want because the types are compatible for the
implied assignment of the argument to the parameter. Consider that
the following is legal because the implied conversion is allowed
void *x;
MD5_CTX y;
x = &y;

But a function taking a void* is not the same type as a function
taking a MD5_CTX*. More importantly, they are not compatible for the
implied assignment. Consider that the following is not legal because
the implied conversion is not allowed (you could cast but that is a
different story)
void (*func)(void*);
void MD5_Init(MD5_CTX *c);
func = MD5_INIT;

If you can't do it with an assignment, you can't do it with
initialization (excluding the obvious exception of initializing a char
array with a string which cannot be done with assignment).
[color=blue]
>void MD5_Update(MD5_CTX *c, const void *data, unsigned long len);
>void MD5_Final(unsigned char *md, MD5_CTX *c);
>
>with different types for the context. short of writing a wrapper
>function for each of these (or one smart wrapper function for them
>all), is there a safe solution to fix these assignments? while i'm at
>it, please post other corrections are you see fit to call them.
>[/color]
Why not declare and define the functions to match the struct members
(take void* as arguments) and inside each function convert the void*
parameter to the correct pointer type. Something like
void MD5_Init(void *x){
MD5_CTX *c = x;
and the rest of your function body can remain unchanged.


<<Remove the del for email>>

re: function pointer casting

On 30 Apr 2004 21:17:25 -0700, joe_bruin@hotmail.com (joe bruin)
wrote:
[color=blue]
>hello all.
>
>i am trying to get rid of some warnings and do "the right thing".
>although in this particular case, i am not sure what the right thing
>is.
>
>the code:
>
>typedef struct
>{
> void *ctx;
> void (*init)(void *);[/color]

Here you say the second member of the struct is a function pointer
whose argument is void*.
[color=blue]
> void (*update)(void *, const void *, unsigned long);
> void (*final)(unsigned char *, void *);
> int mdlen;
> char *name;
>} digest_t;
>
>MD2_CTX md2ctx;
>MD4_CTX md4ctx;
>MD5_CTX md5ctx;
>SHA_CTX shactx;
>RIPEMD160_CTX rmdctx;
>
>digest_t dig[] =
>{
> { &md2ctx, MD2_Init, MD2_Update, MD2_Final,
> MD2_DIGEST_LENGTH, "MD2" },
> { &md4ctx, MD4_Init, MD4_Update, MD4_Final,
> MD4_DIGEST_LENGTH, "MD4" },
> { &md5ctx, MD5_Init, MD5_Update, MD5_Final,
> MD5_DIGEST_LENGTH, "MD5" },[/color]

Here you initialize an instance of the struct and the second member is
initialized to the address of MD5_Init.
[color=blue]
> { &shactx, SHA_Init, SHA_Update, SHA_Final,
> SHA_DIGEST_LENGTH, "SHA" },
> { &shactx, SHA1_Init, SHA1_Update, SHA1_Final,
> SHA_DIGEST_LENGTH, "SHA1" },
> { &rmdctx, RIPEMD160_Init, RIPEMD160_Update, RIPEMD160_Final,
> RIPEMD160_DIGEST_LENGTH, "RIPEMD160" }
>};
>
>this code will yield a "warning: initialization from incompatible
>pointer type", on every Init, Update, and Final function in dig[].
>these functions are all in the format:
>
>void MD5_Init(MD5_CTX *c);[/color]

But the function MD5_Init actually takes a pointer to MD5_CTX which
apparently is not the same as pointer to void.

When calling a function that expects a void*, you can pass any kind of
object pointer you want because the types are compatible for the
implied assignment of the argument to the parameter. Consider that
the following is legal because the implied conversion is allowed
void *x;
MD5_CTX y;
x = &y;

But a function taking a void* is not the same type as a function
taking a MD5_CTX*. More importantly, they are not compatible for the
implied assignment. Consider that the following is not legal because
the implied conversion is not allowed (you could cast but that is a
different story)
void (*func)(void*);
void MD5_Init(MD5_CTX *c);
func = MD5_INIT;

If you can't do it with an assignment, you can't do it with
initialization (excluding the obvious exception of initializing a char
array with a string which cannot be done with assignment).
[color=blue]
>void MD5_Update(MD5_CTX *c, const void *data, unsigned long len);
>void MD5_Final(unsigned char *md, MD5_CTX *c);
>
>with different types for the context. short of writing a wrapper
>function for each of these (or one smart wrapper function for them
>all), is there a safe solution to fix these assignments? while i'm at
>it, please post other corrections are you see fit to call them.
>[/color]
Why not declare and define the functions to match the struct members
(take void* as arguments) and inside each function convert the void*
parameter to the correct pointer type. Something like
void MD5_Init(void *x){
MD5_CTX *c = x;
and the rest of your function body can remain unchanged.


<<Remove the del for email>>

re: function pointer casting

In article <c6vg4h$ipc$1@216.39.135.16>, Barry Schwarz <schwarzb@deloz.net> writes:[color=blue]
>
> Why not declare and define the functions to match the struct members
> (take void* as arguments) and inside each function convert the void*
> parameter to the correct pointer type. Something like
> void MD5_Init(void *x){
> MD5_CTX *c = x;
> and the rest of your function body can remain unchanged.[/color]

There's at least one good reason not to do this: if the functions are
ever called directly, rather than through a digest_t variable,
they've lost type safety on the first parameter. It's easy to
imagine a cut-and-paste mistake that would pass an MD2_CTX* where an
MD4_CTX* was expected, for example.

In this particular case, it may be that the functions are only ever
invoked through the structure members, and so type safety on the
first parameter is moot; the structure has to lie about the type of
the first parameter in order to accomodate all the digest functions.

However, in general I'd consider this a case where I'd prefer to keep
the functions declared strictly and cast them when initializing
members of the array - if I did something like this at all. That's
assuming I knew that the implementation used interchangeable function
pointer representations for void (*)(void *) and void (*)(MD2_CTX *),
and so forth.

Alternatively, define wrappers for each of the three functions for
each of the digest types, which take a void* for the first parameter
and call the properly-declared, "public" version of the function.
That requires defining a bunch of wrappers, but you eliminate the
casts and maintain type safety if the functions are called directly.

Yet another - even safer - alternative is to create a wrapper type
for the various context types. The wrapper is a struct with an enum
identifying the context type and a union of the context types. All
the digest functions are changed to take a pointer to this new
wrapper structure and verify that the context is of the correct type.
That gives you a single function pointer type for digest_t and
run-time type safety, so that calls through digest_t variables are
type-checked.

--
Michael Wojcik michael.wojcik@microfocus.com

The way things were, were the way things were, and they stayed that way
because they had always been that way. -- Jon Osborne