Re: [PATCH 2.4.33-rc1] repair __ide_dma_no_op breakage

[Mikael Pettersson]

On Sat, 17 Jun 2006 23:26:12 +0200, Willy Tarreau wrote:
>> This patch to ide-dma.c defines a function 'int __ide_dma_no_op(void)'
>> and stores its address in function pointer fields with type
>> 'int (*)(ide_drive_t*)'. Thus callers will call __ide_dma_no_op() with
>> more parameters than it expects.
>>
>> This is invalid C and it will break horribly in some valid calling
>> conventions (in particular, when parameters are passed on the stack
>> and the callee not the caller pops them).
>
>I 100% agree with your analysis and you fix, but just out of curiosity,
>when could we encounter such circumstances ? On specific archs or when
>functions are declared in a certain manner ?

I suspect that no currently supported architecure is affected as long
as default calling conventions are used, but i386 would be affected if
__attribute__((stdcall)) is in effect. I suspect m68k is in a similar
situation as i386.

> I've always learned that
>in C, it's always the caller which pops, reason why var args are possible
>and the args type checking is very loose.

What you describe is the typical implementation, but it is a historical
accident and not necessarily the best choice from a performance
perspective. Before ANSI-C introduced prototypes, there was no way to
distinguish variadic from non-variadic functions. Thus all functions
had to use the same conventions, which typically were caller-pops since
that's what's needed for variadic functions. With prototypes it's usually
better to use a callee-pops convention, since that tends to reduce code
space and it allows for tailcalls without blowing the stack. Unfortunately
binary compatibility with pre-ANSI-C object code meant that most if not
all ABIs kept their pre-ANSI-C rules, i.e. caller-pops.

/Mikael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/