develooper Front page | perl.perl5.porters | Postings from January 2013

Re: Should inline.h be renamed inline.c ?

Thread Previous
From:
Karl Williamson
Date:
January 13, 2013 01:18
Subject:
Re: Should inline.h be renamed inline.c ?
Message ID:
50F20B75.8060603@khwilliamson.com
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


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About