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