Front page | perl.perl5.porters |
Postings from July 2010
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. > > Having received no reports of failures, I have applied this change to the > repository as commit 17a6c8e38505fd8d5700febfe392e470c9c5fff8 , > and also updated the metaconfig repository as commits > commits 907a968f1883e76eea71816c9428d036dcfff971 and > bed4b4c1ddba06b9f4653f7769acf6c91b9cba58 . > > I have also updated the guesses in the canned configuration files > for epoc, symbian, uconfig, Cross, and plan9. > > Still needed are updates to VMS and Windows, and Netware. > 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. 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 ? 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.Thread Previous | Thread Next