We should use long long support on the Mac
The HAVE_LONG_LONG issue was previously discussed in bug #3616 and was resolved WONTFIX for the following reason (sdagley@netscape, 1999-05-07 11:53): 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. Is the compatibility of PRUint64 with Apple's Unsigned Wide type still a requirement?
Looking in MacTypes.h, it seems that UnsignedWide is actually defined as an unsigned long long if TYPE_LONGLONG is defined. So this should not be a problem.
I will take your recommendation as to whether we should turn on HAVE_LONG_LONG on Mac. If you think this is the right thing to do, I will review your patch (or you can verify my patch), and then one of you or I can check it in.
Status: NEW → ASSIGNED
As I recall from the days of Mozilla Classic we ran into a problem with defining HAVE_LONG_LONG (in the JS code as I recall) but I don't think this was ever revisited in the new world of Mozilla. If we can build with it turned on I see no reason not to make the change.
Do you guys want to make this change? Does this require a nsbeta3+ status? Or should we wait until Netscape 6.1/NSPR 4.1?
I checked in the patch on the main trunk. /cvsroot/mozilla/nsprpub/pr/src/md/mac/mactime.c, revision 3.7 /cvsroot/mozilla/nsprpub/pr/src/md/mac/prcpucfg.h, revision 3.8 So the HAVE_LONG_LONG macro will be defined in NSPR 4.1. Let me know if you want this change in Netscape 6.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
When doing a verification build of SeaMonkey M17 against NSPR 4.1 (pre-release), I found that at least three files are accessing the 'hi' and 'lo' members of PRInt64/PRUint64, which aren't there if HAVE_LONG_LONG is defined. So I'm afraid that I'll have to back out this change from NSPR 4.1.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Created attachment 13729 [details] Patch to back out the HAVE_LONG_LONG define from prcpucfg.h for Mac.
I backed out the HAVE_LONG_LONG define from prcpucfg.h for Mac. /cvsroot/mozilla/nsprpub/pr/src/md/mac/prcpucfg.h, revision: 3.9 The HAVE_LONG_LONG macro define can be easily put back in when the Mozilla code is ready for it.
Status: REOPENED → ASSIGNED
Target Milestone: 4.1 → Future
wtc: it would much better to change those places that access .hi and .lo to use the correct macros, so that we can use HAVE_LONG_LONG. That will prevent future bustage. Please list those places here, so we can get them fixed.
I only did the Mozilla build. I didn't do the commercial build, so I don't know if any files in the Netscape /m/src/ns tree access .hi and .lo. In the Mozilla build, three files acces .hi and .lo: 1. mozilla:xpcom:reflect:xptcall:src:md:mac:xptcstubs_mac.cpp 2. mozilla:xpcom:io:nsFileSpecMac.cpp 3. mozilla:xpcom:io:nsLocalFileMac.cpp It's simple to change nsFileSpecMac.cpp and nsLocalFileMac.cpp to use the correct macros, but I don't know how to fix xptcstubs_mac.cpp.
*** This bug has been marked as a duplicate of 3616 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago → 18 years ago
Resolution: --- → DUPLICATE
Target Milestone: Future → 4.2
You need to log in before you can comment on or make changes to this bug.