summaryrefslogtreecommitdiff
path: root/installperl
diff options
context:
space:
mode:
authorJarkko Hietaniemi <jhi@iki.fi>2015-11-01 12:55:49 -0500
committerJarkko Hietaniemi <jhi@iki.fi>2015-11-01 17:12:40 -0500
commita4570f51dba109184d92dcbb0612242d942856fc (patch)
treea06d8d083756515411642bc4e3fd63aae707b00e /installperl
parent3b56f80d7e288a7d983d9a6199a8d2cfb87a9e1b (diff)
downloadperl-a4570f51dba109184d92dcbb0612242d942856fc.tar.gz
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.
Diffstat (limited to 'installperl')
0 files changed, 0 insertions, 0 deletions