Define HAVE_LONG_LONG in prcpucfg.h on the Mac.

RESOLVED DUPLICATE of bug 3616

Status

P3
normal
RESOLVED DUPLICATE of bug 3616
19 years ago
18 years ago

People

(Reporter: wtc, Assigned: wtc)

Tracking

PowerPC
Mac System 8.5

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Assignee)

Description

19 years ago
We should use long long support on the Mac
(Assignee)

Comment 1

19 years ago
Created attachment 11276 [details] [diff] [review]
Proposed patch.
(Assignee)

Comment 2

19 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

19 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

19 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

19 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

18 years ago
Target Milestone: --- → 4.1
(Assignee)

Comment 6

18 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

18 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
Last Resolved: 18 years ago
Resolution: --- → FIXED
(Assignee)

Comment 8

18 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

18 years ago
Created attachment 13729 [details]
Patch to back out the HAVE_LONG_LONG define from prcpucfg.h for Mac.
(Assignee)

Comment 10

18 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

18 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

18 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

18 years ago

*** This bug has been marked as a duplicate of 3616 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago18 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.