This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Guidance please: static or extern __inline__
- From: Kean Johnston <jkj at sco dot com>
- To: Mike Stump <mrs at apple dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Fri, 29 Jul 2005 15:03:03 -0700
- Subject: Re: Guidance please: static or extern __inline__
- References: <4195377E-0076-11DA-BCD4-003065BDF310@apple.com>
- Reply-to: jkj at sco dot com
That's a pretty neat trick.
I know, we've filed a patent for it, wait for it, no, wait, ok, just
kidding... :-)
Hehehehe :)
I dont suppose I could trouble you to give me the voodoo required for
inserting an extra pushl before the call could I?
Not sure exactly what you want, but with the below I think it will be
obvious how to do it.
void ioctl(int, unsigned long, char *) __attribute__((always_inline));
asm inline void ioctl(int fd, unsigned long m, char *buf) {
movl #42, 12($esp)
movl fd, 8($esp)
movl m, 4($esp)
movl buf, ($esp)
call _xioctl
xorl $eax, $eax
leave
ret
}
That does help with teh general mechanism. Unfortunately I can't
use inline, becuase ioctl is supposed to be declared as
int ioctl (int, int, ...);. I dont think you can have variadic
inline's can you?
This whole notion of fixing ABI issues in header files makes
my you-know-what's ache. Of course the *rest* of the world
has decent symbol versioning, but some of us are left in the
approximate mid-90's :(
I think I may just cheat and declare ioctl incorrectly, and
put in the 3rd arg. I suspect that is the path of least
resistance, although I have no doubt it will break some
standard. But since I'm shooting for a working, real-world
compiler, I find myself strangely comfortable with the idea
of ignoring a miniscule subclause here and there in a
standard I'm not certifying to :)
Thanks for all your help tho. It's much appreciated.
Kean