Re: [UPDATED PATCH] fix memory corruption from misinterpretedbad_inode_ops return values

[Linus Torvalds]

On Thu, 4 Jan 2007, Andrew Morton wrote:

> On Thu, 04 Jan 2007 12:33:59 -0600
> Eric Sandeen <sandeen@xxxxxxxxxx> wrote:
> 
> > Andrew Morton wrote:
> > > On Thu, 04 Jan 2007 11:51:10 -0600
> > > Eric Sandeen <sandeen@xxxxxxxxxx> wrote:
> > 
> > >> Also - is it ok to alias a function with one signature to a function with
> > >> another signature?
> > > 
> > > Ordinarily I'd say no wucking fay, but that's effectively what we've been
> > > doing in there for ages, and it seems to work.
> > 
> > Hmm that gives me a lot of confidence ;-)  I'd hate to carry along bad
> > assumptions while we try to make this all kosher... but I'm willing to
> > defer to popular opinion on this one....
> 
> yeah, I'm a bit wobbly about it.  Linus, what do you think?

I don't much care. If we ever find an architecture where it matters, we'll 
unalias them. In the meantime, we've for the longest time just known that 
calling conventions don't care about argument types on all the 
architectures we've been on, so we've aliased things to the same function.

But it's not very common, so we can stop doing it. 

But I'd argue we should only do it if there is an actual 
honest-to-goodness reason to do so. Usually it only matters for

 - return types are fundamentally different (FP vs integer vs pointer)

 - calling convention has callee popping the arguments (normal in Pascal, 
   very unusual in C, because it also breaks lots of historical code, 
   and is simply not workable with K&R C, where perfectly normal things 
   like "open()" take either two or three arguments without being 
   varargs).

In general, this just isn't an issue for the kernel. Other systems have 
had basically NO typing what-so-ever for functions, and use aliasing much 
more extensively. We only do it for a few ratehr rare things.

			Linus
-
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/