On 12/31/2012 06:48 PM, bulk88 wrote: > Karl Williamson wrote: >> porting/args_assert.t only looks for .c files. If a function is >> placed into inline.h which has such assertions, args_assert.t won't >> find them, and fails. >> >> We could add a special case into args_assert.t for inline.h, or we >> could rename inline.h to be inline.c. >> >> The other header files that contain inline functions have a .c suffix >> already, such as dquote_static.c > > inline.h explains better what it does than inline.c. inline.c might be > to the uninitiated, a bunch of hot or performance critical code > identical in concept to the pp_hot.c file. Perl XS/internals are > notorious for being unhackable (culture, not security) to the general > public. If it ends with .c, then you assume it is a compiland and a > separate object file. Until you open the file read its comments, you > think it was left in CORE directory as a bug. Currently in 5.17, CORE > directory only winds up with libraries and .h files, no .c or .xs files, > on Win32. > No one else commented, so I'm leaving it inline.h and changing args_assert.t. Note, though, that there exist .c files that are #included for their inline functions.Thread Previous