This is a live mirror of the Perl 5 development currently hosted at https://github.com/perl/perl5
Workaround for perl #124212: these functions are not true static inline
authorJarkko Hietaniemi <jhi@iki.fi>
Sun, 1 Nov 2015 17:55:49 +0000 (12:55 -0500)
committerJarkko Hietaniemi <jhi@iki.fi>
Sun, 1 Nov 2015 22:12:40 +0000 (17:12 -0500)
commita4570f51dba109184d92dcbb0612242d942856fc
treea06d8d083756515411642bc4e3fd63aae707b00e
parent3b56f80d7e288a7d983d9a6199a8d2cfb87a9e1b
Workaround for perl #124212: these functions are not true static inline

By "true" I mean that they have prototypes, but no bodies.

So don't declare their prototypes under PERL_NO_INLINE_FUNCTIONS.

After some studying of http://www.greenend.org.uk/rjk/tech/inline.html
it seems like Perl is trying to implement the "simple portable" model.

But the functions listed as failing during porting/extrefs.t in Tru64:
they are neither fish nor fowl.  Their prototypes are listed in
proto.h as PERL_STATIC_INLINE (which in Tru64 is "static inline"),
but since the test is built with -DPERL_NO_INLINE_FUNCTIONS,
the function bodies (which would be in inline.h) are not visible.
So they end up being body-less static inline prototypes, which is,
I believe, somewhat of an oxymoron.

The "complicated portable" model might be a more wortwhile longer
term goal: in that, there is no "static inline", and there would be
a new source file, say, inline.c.  Now with the "simple portable",
the bodies might end up being compiled multiple times, multiple copies
ending up in different object files, depending on how smart the
compiler/linker is.

Another move could be that maybe there should be no prototypes at all
for inlineables, because having those is kind beside the point.  How
well that would work across different compilers is unknown.

Yet another move, perhaps the simplest one, would be to move these
particular functions away from inline.h.  But this would be just
dodging the larger problems discussed above.
embed.fnc
embed.h
proto.h