Front page | perl.perl5.porters |
Postings from July 2010
Re: [PATCH] Configure probe for static inline (version 2)
Thread Previous
|
Thread Next
From:
Andy Dougherty
Date:
July 27, 2010 13:14
Subject:
Re: [PATCH] Configure probe for static inline (version 2)
Message ID:
alpine.DEB.2.00.1007271604280.6296@fractal.phys.lafayette.edu
On Sun, 25 Jul 2010, karl williamson wrote:
> Andy Dougherty wrote:
> > On Sat, 10 Jul 2010, Vincent Pit wrote:
> >
> > > > Here is a proposed patch to enable Configure to probe for C99-style
> > > > 'static inline'. (That is, functions may be inlined, but will not be
> > > > externally visible.) The initial idea is that some common code in messy
> > > > macros inside headers might be simplified using inline functions. If
> > > > the
> > > > compiler does not support 'static inline', then a plain 'static' is used
> > > > instead, along with the consequent implications of a function call. In
> > > > either case, you simply use PERL_STATIC_INLINE.
> >
> What to do about utility functions that are in .c files? The post above says
> the 'initial idea'. So, should we wait to see how that pans out? And that
> later the facility will be extended, if possible, to separately compiled .o's.
That is for the future. It's not obvious what it means to "inline" a
function from a different .o file. Different C implementations have
historically done different things with functions that are both declared
as "inline" and that you want to be available to be called from another
compilation unit. Configure doesn't probe for any of that yet.
> Or should those functions be moved to a header that is included only by the
> .c's that use the function, such as foo_inline.h ?
Right now, this is the only thing that will work. Functions intended to
be "inline" have to be in the same compilation unit. Making a private
header, such as foo_inline.h, is one way to do that.
> As I said earlier, I have a candidate function, regcurly that once was static
> but when toke.c started using it in addition to regcomp, that had to be
> changed, and there are places where its code is duplicated instead of calling
> it.
Yes, I remember your example. Unfortunately, since regcurly is now an
external function, I have to don my compatibility hat and ask if we need
to retain that external function, and perhaps define a *new* function,
regcurly-inline (?) that is an inline implementation of the function.
In short, I haven't forgotten, but that case is messier than I would have
liked. It's still on my to-do list.
Can you give me some specific references to places where regcurly is
duplicated rather than actually called?
Thanks,
--
Andy Dougherty doughera@lafayette.edu
Thread Previous
|
Thread Next