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
From:
Peter Martini
Date:
October 26, 2013 09:10
Subject:
Re: [perl #120314] t/re/fold_grind.t spews tons of "Attempt to freetemp prematurely" warnings on DEBUGGING but ultimately passes
Message ID:
CAFyW6MTPBsj3D+ifsBmXjAzsandoG1Ak9Rv=18OaFmJeJAKYbA@mail.gmail.com
On Fri, Oct 25, 2013 at 12:24 AM, Father Chrysostomos via RT
<perlbug-followup@perl.org> wrote:
> On Thu Oct 24 19:55:58 2013, craig.a.berry@gmail.com wrote:
>> On Thu, Oct 24, 2013 at 11:32 AM, Vincent Pit <perl@profvince.com>
>> 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
>> <http://www.nntp.perl.org/group/perl.perl5.porters/2011/07/msg174792.html>.
>
> 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?

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?

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About