segfaulting on startup

[Russ Allbery]

Jeffrey M Vinocur <jeff at litech.org> writes:

> With much help from Zack, I found it.  If the Perl headers redefine bool
> (which they do), then any struct (say SITE) which has enough consecutive
> bools that alignment concerns allow them to be compressed (if, say, bool
> is char) is going to be horribly broken if the header file which
> included it is sometimes used with one kind of bool and sometimes with
> another.

Ah!  That makes a great deal of sense.

> On the plus side, it's our own fault, I guess.  Glancing through the
> Perl headers it seems that we're supposed to define HAS_BOOL.  (And in
> fact, doing that in innperl.h fixes the problem for me.)

> So Russ -- if you're happy with your changes, good.

I think I'm happy with the current approach; perl.h pulls in a whole mess
of namespace pollution that I'm not happy with including everywhere
innperl.h is included.  But what I may do instead is drop any pretense of
using the standard version of ppport.h and instead have it include the
Perl headers with fixes like that.

> If there's anything that you'd like to further clean up, the trick is
> just to define HAS_BOOL.  In fact, that's probably very wise to do
> before including the Perl headers anyway...do you want to, or should I
> look into it?

I'll take a look at it sometime fairly soon.

> (Amusingly enough, if you google for HAS_BOOL you mostly get Russ
> talking about INN's bool type.)

Yeah, now I understand why inn/defines.h was defining HAS_BOOL.  Actually,
let me go add that back in for the short term to avoid any problems until
we figure out how we want to do this long-term.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.