segfaulting on startup
rra at stanford.edu
Tue Mar 12 23:30:10 UTC 2002
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
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.
More information about the inn-workers