sun wkshop build bustage: non-NSPR boolean types in nsStorageStream.{h,cpp}




19 years ago
19 years ago


(Reporter: dmose, Assigned: fur)



Firefox Tracking Flags

(Not tracked)




19 years ago

seems to fix the problem in my local tree.

Comment 1

19 years ago
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.

Comment 2

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

Comment 3

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

Comment 4

19 years ago
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.

Comment 5

19 years ago
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

Comment 6

19 years ago
Oh yeah, before I forget: Rah, bah, bah

Comment 7

19 years ago
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:


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.

Comment 8

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

Comment 9

19 years ago
Incidentally, Sun workshop 5, released more than a year ago, supports the bool

Comment 10

19 years ago
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.

Comment 11

19 years ago
"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.

Comment 12

19 years ago
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.


19 years ago
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 13

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

Comment 14

19 years ago
Thanks, Chris - you beat me to it.

Comment 15

19 years ago
Bulk move of all Cache (to be deleted component) bugs to new Networking: Cache

Comment 16

19 years ago
marking verified per chris's comments
You need to log in before you can comment on or make changes to this bug.