Closed
Bug 45223
Opened 24 years ago
Closed 23 years ago
Define HAVE_LONG_LONG in prcpucfg.h on the Mac.
Categories
(NSPR :: NSPR, defect, P3)
Tracking
(Not tracked)
4.2
People
(Reporter: wtc, Assigned: wtc)
Details
Attachments
(2 files)
2.23 KB,
patch
|
Details | Diff | Splinter Review | |
591 bytes,
text/plain
|
Details |
We should use long long support on the Mac
Assignee | ||
Comment 1•24 years ago
|
||
Assignee | ||
Comment 2•24 years ago
|
||
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?
Comment 3•24 years ago
|
||
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.
Assignee | ||
Comment 4•24 years ago
|
||
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
Comment 5•24 years ago
|
||
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.
Assignee | ||
Updated•24 years ago
|
Target Milestone: --- → 4.1
Assignee | ||
Comment 6•24 years ago
|
||
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?
Assignee | ||
Comment 7•24 years ago
|
||
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
Closed: 24 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 8•24 years ago
|
||
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 → ---
Assignee | ||
Comment 9•24 years ago
|
||
Assignee | ||
Comment 10•24 years ago
|
||
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
Comment 11•24 years ago
|
||
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.
Assignee | ||
Comment 12•24 years ago
|
||
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.
Assignee | ||
Comment 13•23 years ago
|
||
*** This bug has been marked as a duplicate of 3616 ***
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 23 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.
Description
•