linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* bad function ptrs - is it dangerous ?
@ 2002-10-01 22:51 J.A. Magallon
  2002-10-01 23:56 ` Burton Samograd
  0 siblings, 1 reply; 3+ messages in thread
From: J.A. Magallon @ 2002-10-01 22:51 UTC (permalink / raw)
  To: Lista Linux-Kernel

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 <jamagallon@able.es>      \                 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))

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: bad function ptrs - is it dangerous ?
  2002-10-01 22:51 bad function ptrs - is it dangerous ? J.A. Magallon
@ 2002-10-01 23:56 ` Burton Samograd
  0 siblings, 0 replies; 3+ messages in thread
From: Burton Samograd @ 2002-10-01 23:56 UTC (permalink / raw)
  To: Lista Linux-Kernel

[-- Attachment #1: Type: text/plain, Size: 1069 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: bad function ptrs - is it dangerous ?
@ 2002-10-02  8:06 Mikael Pettersson
  0 siblings, 0 replies; 3+ messages in thread
From: Mikael Pettersson @ 2002-10-02  8:06 UTC (permalink / raw)
  To: jamagallon; +Cc: linux-kernel

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2002-10-02  8:00 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-10-01 22:51 bad function ptrs - is it dangerous ? J.A. Magallon
2002-10-01 23:56 ` Burton Samograd
2002-10-02  8:06 Mikael Pettersson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).