s/bool/PRBool/ s/true/PR_TRUE/ s/false/PR_FALSE/ seems to fix the problem in my local tree.

bool is a standard C++ type that any ANSI conformant compiler should support. PRBool, on the other hand, is a typedef that is leftover from the pre-C++ days of NSPR. You get better compiler type-checking when using bool. More importantly, there are things that can only be done if bool is a distinct type different from PRBool, i.e. the ability to overload methods and operators which make a distinction between bool and integer types. If your compiler can't handle the bool type in this file, I would check for a conflicting header file or some command-line flag.

*** Bug 19067 has been marked as a duplicate of this bug. ***

Many commercial C++ compilers are still pre-ANSI, and thus need PRBool. Unfortunate but true...

When you say "bool is a distinct type different from PRBool" don't you really mean "bool is a distinct type from integer?" If so, then a better solution might be that autoconf figures out if your compiler supports bool or not, and if so, typedefs PR_Bool to bool, otherwise falls back to it's current integer implemention.

Yes, PRBool is typedef'ed as an integer. My point was that if your boolean type is also an integer (as you are proposing by adding a typedef in the case of non-ANSI compilers), then certain C++ features don't work, such as non-conflicting overloaded methods/operators for bool and integer argument types. ANSI didn't make bool a built-in C++ type for the hell of it - if it could have been done with a typedef, they would have left it out of the language.

Oh yeah, before I forget: Rah, bah, bah

I'm aware that the typedef solution isn't as good on the pre-ANSI compilers. I was more addressing the type-checking problem you mentioned, and figuring that better type-checking on some compilers is worth it. As far as the overloading goes, our C++ portability guide warns that this sort of overloading is not a particularly good idea: <http://www.mozilla.org/hacking/portable-cpp.html#signatures> Mozilla needs to continue to be very portable code. As djw says in the portability guide: Some of these things will frustrate you and make you want to throw your hands up and say, ``well, that's just a stupid compiler if it doesn't do <insert favorite C++ feature>.'' But this is the reality of portable code.

dmose, you obviously did not read my last comment on this bug

Incidentally, Sun workshop 5, released more than a year ago, supports the bool type.

You mean the "Rah bah bah" comment? Actually, I read it but didn't have the faintest understanding of what it might mean. And still don't. Up until yesterday, Workshop 4.2 could build Mozilla just fine.

"Rah, bah, bah", is a quote from a "The Tick" episode with aged super-villains. It's grumpy old man noises. I know damn well about C++ portability - I've been dealing with these issues since the early '90s. I'm just resenting it.

Turns out configure already does check for boolean type support: it #defines NEEDS_bool to 1 if the support is not found. A quick glance at lxr seems to suggest that mozilla doesn't actually reference that #define anywhere yet, but it is there.

We don't build with C++ specs, we build with compilers. this is a standard unix fix, I agree with dmose here. Fixed.

Thanks, Chris - you beat me to it.

Bulk move of all Cache (to be deleted component) bugs to new Networking: Cache component.

marking verified per chris's comments