Front page | perl.perl5.porters |
Postings from July 2010
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 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