45223 - Define HAVE_LONG_LONG in prcpucfg.h on the Mac.

Status: RESOLVED DUPLICATE of bug 3616

(NSPR :: NSPR, defect, P3)

Description

[Wan-Teh Chang]

We should use long long support on the Mac

Comment 1

[Wan-Teh Chang]

Attachment: Proposed patch.

Comment 2

[Wan-Teh Chang]

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

[Simon Fraser [no longer active]]

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.

Comment 4

[Wan-Teh Chang]

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.

Comment 5

[Steve Dagley]

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.

Comment 6

[Wan-Teh Chang]

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?

Comment 7

[Wan-Teh Chang]

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.

Comment 8

[Wan-Teh Chang]

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.

Comment 9

[Wan-Teh Chang]

Attachment: Patch to back out the HAVE_LONG_LONG define from prcpucfg.h for Mac.

Comment 10

[Wan-Teh Chang]

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.

Comment 11

[Simon Fraser [no longer active]]

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.

Comment 12

[Wan-Teh Chang]

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.

Comment 13

[Wan-Teh Chang]

*** This bug has been marked as a duplicate of 3616 ***