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

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

Thread Next
From:
karl williamson
Date:
August 2, 2010 16:27
Subject:
[perl #76936] Re: [PATCH] Configure probe for static inline (version 2)
Message ID:
rt-3.6.HEAD-2463-1280791658-1442.76936-75-0@perl.org
# New Ticket Created by  karl williamson 
# Please include the string:  [perl #76936]
# in the subject line of all future correspondence about this issue. 
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=76936 >


Andy Dougherty wrote:
> 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.

I deliberately left this function out of the public API, by omitting the 
flag in embed.fnc that would have done so.  This prompted me to look at 
the pods, and realized that now perlapi lists every function that is in 
the public API, documented or not.  So attached is a patch for 
consideration that attempts to clarify that if a function isn't listed 
in that pod, it is definitely not a candidate for use.
> 
>> 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 Next


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