[PP]long long support in Mac NSPR

RESOLVED FIXED in 4.2

Status

P3
normal
RESOLVED FIXED
20 years ago
18 years ago

People

(Reporter: sfraser_bugs, Assigned: sdagley)

Tracking

other
PowerPC
Mac System 8.5

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: have patches, waiting for mozilla.9 smoke to clear before landing)

Attachments

(2 attachments)

(Reporter)

Description

20 years ago
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.

Updated

20 years ago
Target Milestone: M4

Comment 1

20 years ago
Changed target milestone to M4.

Updated

20 years ago
Target Milestone: M4

Comment 2

20 years ago
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.

Updated

20 years ago
Target Milestone: M4
(Reporter)

Comment 3

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

Updated

20 years ago
Status: NEW → ASSIGNED

Comment 4

20 years ago
Changed target milestone to M6.

Updated

20 years ago
Summary: long long support in Mac NSPR → [PP]long long support in Mac NSPR
(Assignee)

Updated

20 years ago
Assignee: gordon → sdagley
Status: ASSIGNED → NEW
(Assignee)

Comment 5

20 years ago
Offloading some of gordon's doomage

Comment 6

20 years ago
NSPR now has its own Bugzilla product.  Moving this bug to the NSPR product.
(Assignee)

Updated

20 years ago
Status: NEW → ASSIGNED
(Assignee)

Updated

20 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → WONTFIX
(Assignee)

Comment 7

20 years ago
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.

Updated

20 years ago
Status: RESOLVED → VERIFIED

Comment 8

20 years ago
marking verified.

Updated

19 years ago
Target Milestone: M6 → ---
(Reporter)

Comment 9

18 years ago
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.
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
(Assignee)

Comment 10

18 years ago
Created attachment 28560 [details] [diff] [review]
patch to enable long long support on Mac
(Assignee)

Comment 11

18 years ago
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.
Status: REOPENED → ASSIGNED
(Reporter)

Comment 12

18 years ago
+#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!
(Assignee)

Comment 13

18 years ago
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)
(Assignee)

Updated

18 years ago
Whiteboard: have patches, waiting for mozilla.9 smoke to clear before landing
Target Milestone: --- → 4.2
(Reporter)

Comment 14

18 years ago
sr=sfraser
(Reporter)

Comment 15

18 years ago
Oops, one more thing. Do we need a #pragma in ide_options.h to turn long long on 
globally?
(Assignee)

Comment 16

18 years ago
Shouldn't it be picked up from the NSPR settings?
(Reporter)

Comment 17

18 years ago
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)
(Assignee)

Comment 18

18 years ago
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 20 years ago18 years ago
Resolution: --- → FIXED

Comment 19

18 years ago
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 20

18 years ago
Created attachment 33433 [details] [diff] [review]
A patch that deletes the unused code in mactime.c.
(Assignee)

Comment 21

18 years ago
verified patch to remove obsolete mactime.c code

Comment 22

18 years ago
I checked in my patch for mactime.c on the NSPRPUB_CLIENT_BRANCH.
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 23

18 years ago
*** Bug 45223 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.