develooper Front page | perl.perl5.porters | Postings from August 2010

Re: [PATCH] Configure probe for static inline (version 2)

Thread Previous | Thread Next
From:
Andy Dougherty
Date:
August 2, 2010 06:30
Subject:
Re: [PATCH] Configure probe for static inline (version 2)
Message ID:
alpine.DEB.2.00.1008020924530.10487@fractal.phys.lafayette.edu
On Mon, 2 Aug 2010, Nicholas Clark wrote:

> On Sat, Jul 31, 2010 at 11:29:13AM -0600, karl williamson wrote:
> > karl williamson wrote:
> > >Andy Dougherty wrote:
> > >>On Sun, 25 Jul 2010, karl williamson wrote:
> 
> > >>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.
> 
> That approach appeals to me. It avoids polluting external namespaces with
> (even) more functions.

It's the maximally portable/safe approach, and completely avoids dealing 
with external linkage (and all the conditional complexities that entails 
(think AIX under all its various compiler options, for example)).

> > >I made it an external function in 5.12.0 only because of the need for it 
> > >in re_comp.c.  The API was deliberately not exposed.  It's true that 
> > >someone could have started to use it, but I believe that we don't need 
> > >to preserve an undocumented interface.  Yes? No?
> > 
> > I have since discovered that we specifically say in perlapi.pod that no 
> > interface not documented there can be relied on.  So I claim we don't 
> > have to preserve regcurly as an external function.
> 
> Yes. If it's not public, it's free to be changed.

Fair enough.  I hadn't had time to investigate at all; I had only gotten 
to the point where I realized I had to investigate.

> In practice, even prior to Jesse's new strict maint lockdown approach, 
> for 5.8.x I didn't change the prototypes of any external function, 
> public or not, because I didn't trust someone out there not to have 
> managed somehow to expose the function named mangled with the arguments 
> in some way that dynamic linking would fail (at run time, probably even 
> lazily) if the arguments changed, *and* that they'd then blame *me* for 
> their problem.

For what it's worth, that was generally my bias too.  Of course that may 
only have helped feed the expectations that have since made everyone else 
take such a conservative stance.

Realistically, I doubt I'll have time this week to look at anything 
related to this.

--
    Andy Dougherty		doughera@lafayette.edu


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About