From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-117802-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 14739 invoked by alias); 28 Jul 2005 16:12:38 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 14650 invoked by uid 22791); 28 Jul 2005 16:12:32 -0000
Received: from mail.ut.sco.com (HELO mail.ut.sco.com) (216.250.130.2)
    by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 28 Jul 2005 16:12:32 +0000
Received: (qmail 21505 invoked from network); 28 Jul 2005 16:12:30 -0000
Received: from mail.sco.com (216.250.130.37)
  by mail.ut.sco.com with SMTP; 28 Jul 2005 16:12:30 -0000
Received: from mail.sco.com (localhost [127.0.0.1])
	by localhost (Postfix) with ESMTP id 7F017154AAAB
	for <gcc@gcc.gnu.org>; Thu, 28 Jul 2005 10:12:24 -0600 (MDT)
Received: from [127.0.0.1] (sillenius.vpn.sco.com [192.168.252.123])
	by mail.sco.com (Postfix) with ESMTP id 89EE4154AA05
	for <gcc@gcc.gnu.org>; Thu, 28 Jul 2005 10:12:23 -0600 (MDT)
Message-ID: <42E903E5.4040905@sco.com>
Date: Thu, 28 Jul 2005 16:12:00 -0000
From: Kean Johnston <jkj@sco.com>
Reply-To: jkj@sco.com
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
MIME-Version: 1.0
To: gcc@gcc.gnu.org
Subject: Guidance please: static or extern __inline__
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SW-Source: 2005-07/txt/msg01166.txt.bz2

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 *__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 __inline__' was
the way to go for this type of header file trickery. However,
it caused a problem bootstrapping the compiler, becuase the
first stage doesn't have -O, so any calls to stat() actually
go to the library routine called stat(), which is an old,
deprecated stat that can't deal with, say, 32-bit inodes or
uid_t's etc, and various programs like fixincludes then
fail to stat files.

If things are compiled with -O, everything works fine,
becuase _xstat, which is what I really want, is called. If
I change the extern __inline__ to static __inline__, it
works correctly, even without optimization.

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.

So my question is in two parts I guess:
a) Which is the better thing to use in a header file for
    this type of function mapping? static or extern inline?
b) If its extern inline, is there a way to force the inline
    expansion even when not using -O (and without command
    line options). I wouldn't want users to get nasty
    surprises if they just used 'gcc -o foo foo.c'.

Any advice and guidance greatly appreciated.

Kean