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.eduThread Previous | Thread Next