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

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

Thread Previous | Thread Next
From:
Father Chrysostomos via RT
Date:
October 26, 2013 09:27
Subject:
[perl #120314] t/re/fold_grind.t spews tons of "Attempt to free temp prematurely" warnings on DEBUGGING but ultimately passes
Message ID:
rt-4.0.18-14234-1382779632-1457.120314-15-0@perl.org
On Sat Oct 26 02:11:01 2013, pcm wrote:
> 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?

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
<http://www.nntp.perl.org/group/perl.perl5.porters/;msgid=20110914202736.GN23881@plum.flirble.org>).

> 
> 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.

(Why does VMS need int?)

-- 

Father Chrysostomos


---
via perlbug:  queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=120314

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