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
On Friday, July 29, 2005, at 01:23 PM, Kean Johnston wrote:
[ cough ]
#if _FILE_OFFSET_BITS - 0 == 32
int open (const char *, int, int) asm ("open32");
#elif _FILE_OFFSET_BITS - 0 == 64
int open (const char *, int, int) asm ("open64");
#else
int open (const char *, int, int) asm ("__open");
#e
[ cough ]
#if _FILE_OFFSET_BITS - 0 == 32
int open (const char *, int, int) asm ("open32");
#elif _FILE_OFFSET_BITS - 0 == 64
int open (const char *, int, int) asm ("open64");
#else
int open (const char *, int, int) asm ("__open");
#endif
That's a pretty neat trick. I dont suppose I could
tr
On Jul 28, 2005, at 12:42 PM, Kean Johnston wrote:
[ cough ] "always_inline" [ cough ]
HA!
I *knew* there was a solution. Thank you Mike.
So now I guess the question remains, for the cases where
you want a function to behave differently depending on
pre-processor conditionals, whats the best w
So, can I summarize your question as a way of trying to make "open"
and alias for open32 or open63 and not having to get into the trap of
different function address? If yes, does glibc's weak_alias would
work for you without creating new problems?
Yeah thats pretty much it, but I dont think weak
Kean Johnston <[EMAIL PROTECTED]> writes:
| > [ cough ] "always_inline" [ cough ]
| HA!
|
| I *knew* there was a solution. Thank you Mike.
|
| So now I guess the question remains, for the cases where
| you want a function to behave differently depending on
| pre-processor conditionals, whats the
[ cough ] "always_inline" [ cough ]
HA!
I *knew* there was a solution. Thank you Mike.
So now I guess the question remains, for the cases where
you want a function to behave differently depending on
pre-processor conditionals, whats the best way of doing
it? The particularly interesting case is
On Jul 28, 2005, at 9:12 AM, Kean Johnston wrote:
extern int stat (const char *__p, stat_t *__s);
extern __inline__ int
stat(const char *__p, stat_t *__s)
{
return _xstat(_STAT_VER, __p, __s);
}
However, it caused a problem bootstrapping the compiler, becuase
the first stage do
On Thu, Jul 28, 2005 at 11:31:55AM -0700, Kean Johnston wrote:
> >>However, I *think* I like the semantics of 'extern inline'
> >>better: use the inline version for the most part but if,
> >>for example, you take the address of the function, use the
> >>actual symbol stat(). But I see that most oth
However, I *think* I like the semantics of 'extern inline'
better: use the inline version for the most part but if,
for example, you take the address of the function, use the
actual symbol stat(). But I see that most other fixincs
use static inline.
Huh? This paragraph conflicts with the previ
On Thu, Jul 28, 2005 at 09:12:21AM -0700, Kean Johnston wrote:
> to:
> extern int stat (const char *__p, stat_t *__s);
> extern __inline__ int
> stat(const char *__p, stat_t *__s)
> {
> return _xstat(_STAT_VER, __p, __s);
> }
...
> From reading teh docs it seems like 'extern __inlin
I've long come to the conclulsion that "static inline" is the most
palatable form of the whole thingy -- its semantics does not depend on
optimization level. It is also the form that suits needs for people
who need to write C++ codes that use or interface with C codes.
Thanks for the advice Gaby
Kean Johnston <[EMAIL PROTECTED]> writes:
[...]
| However, I *think* I like the semantics of 'extern inline'
| better: use the inline version for the most part but if,
| for example, you take the address of the function, use the
| actual symbol stat(). But I see that most other fixincs
| use stat
Hi everyone,
I've run into a little SNAFU with my porting work. In my
fixincludes changes I changed all forms in the header files
of (using stat as an example):
static int
stat(const char *__p, stat_t *__s)
{
return _xstat(_STAT_VER, __p, __s);
}
to:
extern int stat (const char *__
14 matches
Mail list logo
