Front page | perl.perl5.porters |
Postings from October 2013
On Sat, Oct 26, 2013 at 5:27 AM, Father Chrysostomos via RT <perlbug-followup@perl.org> wrote: > 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>). 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 > https://rt.perl.org/Ticket/Display.html?id=120314Thread Previous | Thread Next