Casting pointers to varargs functions

[Gene]

Hello all. Is the initializing assignment below ANSI standard-
conforming?

Is there a way to have the prefix parameters to ... type checked in
such an assignment? E.g. in this case int x in the typedef matched
with int a of foo?

Appreciate the help.

------------

#include <stdio.h>

int foo(int a, int b)
{
return a + b;
}

typedef int (*FUNCTION)(int x, ...);

int main(void)
{
FUNCTION p = (FUNCTION)foo;
printf("%d\n", (*p)(1, 2));
return 0;
}

[Eric Sosman]

Gene wrote:

Hello all. Is the initializing assignment below ANSI standard-
conforming?

Yes, but ...

Is there a way to have the prefix parameters to ... type checked in
such an assignment? E.g. in this case int x in the typedef matched
with int a of foo?

Yes, the fixed parameters behave like normal prototyped
parameters, but ...

Appreciate the help.

------------

#include <stdio.h>

int foo(int a, int b)
{
return a + b;
}

typedef int (*FUNCTION)(int x, ...);

int main(void)
{
FUNCTION p = (FUNCTION)foo;
printf("%d\n", (*p)(1, 2));

... but right here your program goes off the rails. The
function pointer type ("pointer to function returning int,
taking an int and variable arguments") does not match the type
of the called function ("function returning int, taking two
int arguments"). When you call a function via a pointer that
doesn't match the function's actual type, the behavior is
undefined.

It's not a matter of caprice. Different machines use
different mechanisms for subroutine linkage, and the "normal"
argument passing mechanism may be unsuitable for variable
argument lists. For example, imagine a machine with separate
CPU registers for integer and floating-point values; a call
to `foo(int x, double y, int z)' might use R0 and R1 for x
and z, and F0 for y. But this convention could be clumsy for
`bar(int q, ...)' even if the remaining arguments in some call
turn out to be a double and an int. An implementation might
invoke bar by passing q in R0 and a pointer to a memory-resident
aggregation of the remaining arguments in R1. If the caller
uses one convention and the callee uses something else, then
"What we have here is a failure to communicate."

--
Eric Sosman
es*****@ieee-dot-org.invalid

[Gene]

On Nov 2, 9:57 pm, Eric Sosman <[e-mail] e:

Gene wrote:

Hello all. Is the initializing assignment below ANSI standard-
conforming?

Yes, but ...

Is there a way to have the prefix parameters to ... type checked in
such an assignment? E.g. in this case int x in the typedef matched
with int a of foo?

Yes, the fixed parameters behave like normal prototyped
parameters, but ...

Appreciate the help.

------------

#include <stdio.h>

int foo(int a, int b)
{
return a + b;
}

typedef int (*FUNCTION)(int x, ...);

int main(void)
{
FUNCTION p = (FUNCTION)foo;
printf("%d\n", (*p)(1, 2));

... but right here your program goes off the rails. The
function pointer type ("pointer to function returning int,
taking an int and variable arguments") does not match the type
of the called function ("function returning int, taking two
int arguments"). When you call a function via a pointer that
doesn't match the function's actual type, the behavior is
undefined.

It's not a matter of caprice. Different machines use
different mechanisms for subroutine linkage, and the "normal"
argument passing mechanism may be unsuitable for variable
argument lists. For example, imagine a machine with separate
CPU registers for integer and floating-point values; a call
to `foo(int x, double y, int z)' might use R0 and R1 for x
and z, and F0 for y. But this convention could be clumsy for
`bar(int q, ...)' even if the remaining arguments in some call
turn out to be a double and an int. An implementation might
invoke bar by passing q in R0 and a pointer to a memory-resident
aggregation of the remaining arguments in R1. If the caller
uses one convention and the callee uses something else, then
"What we have here is a failure to communicate."

--
Eric Sosman
[e-mail]

Thanks Eric. That's just what I need and sort of what I expected.
What if I say instead

typedef int (*FUNCTION)();

? I.e. use no prototype at all for the parameters a la K&R. Is this
now reliable?

(Interesting that gcc doesn't complain about the first first form even
with -Wall --ansi --pedantic.)

[Ian Collins]

Gene wrote:

On Nov 2, 9:57 pm, Eric Sosman <[e-mail] e:

>>
It's not a matter of caprice. Different machines use
different mechanisms for subroutine linkage, and the "normal"
argument passing mechanism may be unsuitable for variable
argument lists. For example, imagine a machine with separate
CPU registers for integer and floating-point values; a call
to `foo(int x, double y, int z)' might use R0 and R1 for x
and z, and F0 for y. But this convention could be clumsy for
`bar(int q, ...)' even if the remaining arguments in some call
turn out to be a double and an int. An implementation might
invoke bar by passing q in R0 and a pointer to a memory-resident
aggregation of the remaining arguments in R1. If the caller
uses one convention and the callee uses something else, then
"What we have here is a failure to communicate."

*Please* don't quote signatures...

>
Thanks Eric. That's just what I need and sort of what I expected.
What if I say instead

typedef int (*FUNCTION)();

? I.e. use no prototype at all for the parameters a la K&R. Is this
now reliable?

If what context? IIRC if you use a K&R style prototype, any parameters
passed will be promoted to int, which might not be what you want.

(Interesting that gcc doesn't complain about the first first form even
with -Wall --ansi --pedantic.)

Not at all, you told it not to complain with that horrible cast!

--
Ian Collins.

[Ben Pfaff]

Ian Collins <ia******@hotma il.comwrites:

If what context? IIRC if you use a K&R style prototype, any parameters
passed will be promoted to int, which might not be what you want.

Point of terminology: "K&R style prototype" is a contradiction in
terms. You can have a declaration that is not a prototype, and
I'd even allow that you can have a K&R-style function definition,
but you can't have a K&R style prototype.
--
Ben Pfaff
http://benpfaff.org

[Ian Collins]

Ben Pfaff wrote:

Ian Collins <ia******@hotma il.comwrites:

>If what context? IIRC if you use a K&R style prototype, any parameters
passed will be promoted to int, which might not be what you want.

Point of terminology: "K&R style prototype" is a contradiction in
terms. You can have a declaration that is not a prototype, and
I'd even allow that you can have a K&R-style function definition,
but you can't have a K&R style prototype.

Fair point.

--
Ian Collins.