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 27, 2010 13:51
Re: [PATCH] Configure probe for static inline (version 2)
Message ID:
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?

> 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 

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