On Thu, 4 Jan 2007, Andrew Morton wrote:
> On Thu, 04 Jan 2007 12:33:59 -0600
> Eric Sandeen <[email protected]> wrote:
>
> > Andrew Morton wrote:
> > > On Thu, 04 Jan 2007 11:51:10 -0600
> > > Eric Sandeen <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
