Hi al...
I have a little question. Let's suppose you have this:
int (*pf)(data *);
int f(data*);
so you can:
pf = f;
pf(data).
Fine. But what happens if:
void (*pf)(data *);
int f(data*);
pf = f; // gcc happily swallows, gcc-3.2 gives a warning.
pf(data).
??
In C calling convention, the callee kills the stack so nothing should
happen... or it should ?
The (in)famous graphics driver all you know is doing this with the
copy_info op for gart...
TIA
--
J.A. Magallon <[email protected]> \ Software is like sex:
werewolf.able.es \ It's better when it's free
Mandrake Linux release 9.0 (dolphin) for i586
Linux 2.4.20-pre8-jam1 (gcc 3.2 (Mandrake Linux 9.0 3.2-1mdk))
On Wed, Oct 02, 2002 at 12:51:25AM +0200, J.A. Magallon wrote:
> I have a little question. Let's suppose you have this:
>
> int (*pf)(data *);
> int f(data*);
>
> so you can:
>
> pf = f;
> pf(data).
>
> Fine. But what happens if:
>
> void (*pf)(data *);
> int f(data*);
>
> pf = f; // gcc happily swallows, gcc-3.2 gives a warning.
> pf(data).
>
> ??
>
> In C calling convention, the callee kills the stack so nothing should
> happen... or it should ?
>
I think that under most calling conventions return values are put into
registers, so this shouldn't do anything other than keep the compiler from
reallocating the designated return register for a while.
Or, after a second or two of more thought, it might cause the function to trash
whatever value is contained in the return register, which the compiler thought
was safe from harm. It all depends on the calling convention and whether the
caller assumes that the callee can destroy any registers or if the callee has to
save and restore the registers it uses.
burton
On Wed, 2 Oct 2002 00:51:25 +0200, J.A. Magallon wrote:
>int (*pf)(data *);
>int f(data*);
>
>so you can:
>
>pf = f;
>pf(data).
>
>Fine. But what happens if:
>
>void (*pf)(data *);
>int f(data*);
>
>pf = f; // gcc happily swallows, gcc-3.2 gives a warning.
>pf(data).
Undefined Behaviour. I can easily imagine cases where, depending
on the calling convention and the actual return type, things could
go very very wrong. Consider struct returns...
This case, returning an int to a caller expecting void, is likely
to work on most normal machines -- the int would go into a GP result
register, and the GP result register is typically always part of the
caller-save set. The code is still utter crap, however.
>The (in)famous graphics driver all you know is doing this with the
>copy_info op for gart...
<censored>
/Mikael