NSPR headers on Mac specify that long long support is not available on Mac. The current compilers do have long long support, so this needs fixing. It's breaking xpidl right now.

Changed target milestone to M4.

We can certainly #define HAVE_LONG_LONG for the Mac. But a bigger question is: does this mean xpidl won't work on systems without long long support? That would be a major problem.

Right now, the xpidl code breaks if long long support is off (recent checking by shaver, I think).

Changed target milestone to M6.

Offloading some of gordon's doomage

NSPR now has its own Bugzilla product. Moving this bug to the NSPR product.

Since xpidl no longer requires NSPR I'm going to mark this as WONTFIX. Changing from the struct based 64 bit type to long long breaks compatability/ interchangability with Apple's Unsigned Wide type which we've mixed and matched with PRUint64 in some places. The good/bad news of investigating this bug is that we've got some potential time calculation problems in the JS code so I'll log a seperate bug on that one.

marking verified.

I'm reopening this. We need long long support, and compatibility with UnsignedWide in the headers is not an issue; we should just fix those places that need to convert between UnsignedWide and long long. The tree just broke *again* because someone messed up with the LL macros.

Patch attached. Looks like most of the conflicting code has been dropped/replaced (IIRC JS was where we had most of the conflicts) and the actual changes are mostly minor. The change for xptcstubs_mac.cpp needs special sr from beard to verify the Classic Mac OS is == to OS X & LinuxPPC for the 64 bit into parameter passing.

+#ifdef HAVE_LONG_LONG + space64Bits = pb.ioVFreeBytes; +#else const UnsignedWide& freeBytes = UInt64ToUnsignedWide(pb.ioVFreeBytes); space64Bits.lo = freeBytes.lo; space64Bits.hi = freeBytes.hi; +#endif Shouldn't this code have used the LL_ macros in the first place (and could do now)? It's in 2 places. Otherwise, it looks good!

I don't think we can use the LL_ macros for this when we're not building for long long. It lools like <Files.h> always declares that struct with a long long (Patrick's comment if you cvsblame the code is that it was done to sync w/ Universal Headers 3.3)

sr=sfraser

Oops, one more thing. Do we need a #pragma in ide_options.h to turn long long on globally?

Shouldn't it be picked up from the NSPR settings?

Hrmm, there is no 'long long' checkbox in the projects prefs; I thought there was. The CodeWarrior docs say: Using 64-bit Integers The C compiler lets you define a 64-bit integer with the type speci-fier long long. This behavior is controlled by the longlong pragma. There is no item in the C/C++ Language Panel to control this option. If this option is on, you may declare a long long integer. A long long can hold values from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. An unsigned long long can hold values from 0 to 18,446,744,073,709,551,615. If this option is off, using long long causes a syntax error. In an enumerated type, you can use an enumerator large enough for a long long. For more information, see “Enumerated Types” on page 33. However, long long bitfields are not supported. You control the long long type with pragma longlong.To check whether this option is on, use __option (longlong). By default, this pragma is on. so I guess we had long long support all along, but just needed to educate NSPR. However, I think, for clarity, we should still add '#pragma longlong on' to IDE_Options.h. (Side note: I've noticed some projects are have inlining turned off, even for opt targets. See bug 77205. Please coordinate changes to IDE_options.h)

Checked in the changes for NSPR long long support. Did NOT check in scc's changes to IDE_Options.h as I was seeing a crash with them. scc hasn't discovered what the problem is yet but this patch was getting kinda stale.

Steve: I've already dealt with mozilla/nsprpub/pr/src/md/mac/mactime.c in bug #45223 (which is really a duplicate of this bug). It turns out that the code that your patch modified can simply be deleted. I am going to attach a patch for that. Please test it and I'll check it in on NSPRPUB_CLIENT_BRANCH.

verified patch to remove obsolete mactime.c code

I checked in my patch for mactime.c on the NSPRPUB_CLIENT_BRANCH.

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