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

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

Thread Previous | Thread Next
karl williamson
July 31, 2010 10:29
Re: [PATCH] Configure probe for static inline (version 2)
Message ID:
karl williamson wrote:
> Andy Dougherty wrote:
>> 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.
> 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.
>> 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?
> Here's the one I happened to notice; I have not gone looking for others 
> until it became apparent what would happen with this: toke.c in 
> S_intuit_more.
> There's a small inefficiency in the existing implementation unless the 
> optimizer gets rid of it.  The while loop after parsing the comma need 
> not be executed unless there was indeed a comma.
>> Thanks,

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About