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

Re: [perl #120314] t/re/fold_grind.t spews tons of "Attempt to freetemp prematurely" warnings on DEBUGGING but ultimately passes

Thread Previous | Thread Next
Peter Martini
October 26, 2013 10:17
Re: [perl #120314] t/re/fold_grind.t spews tons of "Attempt to freetemp prematurely" warnings on DEBUGGING but ultimately passes
Message ID:
On Sat, Oct 26, 2013 at 5:27 AM, Father Chrysostomos via RT
<> wrote:
> On Sat Oct 26 02:11:01 2013, pcm wrote:
>> On Fri, Oct 25, 2013 at 12:24 AM, Father Chrysostomos via RT
>> <> wrote:
>> > On Thu Oct 24 19:55:58 2013, wrote:
>> >> On Thu, Oct 24, 2013 at 11:32 AM, Vincent Pit <>
>> >> wrote:
>> >> >>
>> >> >> But people do manual builds with g++ fairly regularly as a
>> >> >> stricter,
>> >> >> trouble-seeking C.  I think it's just that in the unusual case of
>> >> >> bool, C is where the trouble is.
>> >> >>
>> >> >
>> >> > I think you mean "stricter non-C". :)
>> >>
>> >> When you throw C code at a C++ compiler and it finds real problems
>> >> that a C compiler didn't catch, then for all practical purposes it's
>> >> a
>> >> stricter C compiler.
>> >>
>> >> > The only legitimate use of a C++ compiler to build perl is to
>> >> > check
>> >> > that the
>> >> > headers are both valid C and C++.
>> >>
>> >> In that case, illegitimacy is more fun, or at least of more
>> >> practical
>> >> benefit.  See paragraph 4 of
>> >> <>.
>> >
>> > OK, but could someone comment on my patch that makes even C++ have a
>> > C-style bool under -DDEBUGGING? :-)
>> >
>> A couple of comments:
>> My understanding of the intent of stdbool.h is that its sole purpose
>> is to define bool, true, and false properly.  If we want to go this
>> route, where DEBUGGING forces the traditional behavior, would it be
>> clearer to have Configure unset I_STDBOOL if DEBUGGING was passed?
> I suppose so, but we would still have to shift defines around for Mac OS X, as
> mach-o/dyld.h includes stdbool.h.  (stdbool.h support was added for its sake; see
> <;>).

Ah, thanks for that history, that clears things up.  That means to use
the API needed for relocatable @INC on Mac OS X, we *require* C99
compatibility.  The code that uses that is in perl.c, but it's not hot
code, so it could potentially be moved to a separate .c file where we
could limit the scope of the include to its own private file rather
than a header that everything uses.

Does anyone know what the C99 standard says about _Bool?  I'm having
trouble finding it in Google, and don't have a copy of the standard.

>> The header file stdbool.h was added in C99 for the sole purpose of
>> defining bool, true, and false.  It was done as a header file rather
>> than adding new keywords, so that any existing defines of those tokens
>> didn't break, and anything that wanted the new C99 behavior for those
>> files could just include stdbool.h - anything that wanted to maintain
>> C89 compatibility could opt out of those three keywords by not
>> including the stdbool.h header file.  Incidentally, if we never
>> included stdbool.h, we'd also be missing out on 'true' and 'false',
>> which would catch a similar class of error (that only a smoke on
>> George's VC6 caught when I made it).
>> On another note, can anyone provide context as to why our final
>> fallback to 'define bool char', except for VMS?  Couldn't we just
>> change *that* to be int everywhere, unless otherwise defined?
> That would increase memory usage on C89 compilers.

bulk88: could you change the define for bool from char to int in your
setup?  If it's as simple as that, could you tell us what kind of
effect it has on the size?  I can't think of a better person for that
kind of comparison.

> (Why does VMS need int?)
> --
> Father Chrysostomos
> ---
> via perlbug:  queue: perl5 status: open

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About