nsXPCToolsCompiler.cpp > xpctools_private.h incorrectly uses LL_INIT which breaks for !*HAVE_LONG_LONG

VERIFIED FIXED

Status

()

Core
XPConnect
VERIFIED FIXED
17 years ago
16 years ago

People

(Reporter: timeless, Assigned: timeless)

Tracking

Trunk
x86
FreeBSD
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

17 years ago
basd on Bugzilla Bug 100873 JS Hard Codes JS_HAVE_LONG_LONG to the detriment of 
FreeBSD.

timeless@sorefbsd:~/mozilla/obj-gtk-i386-unknown-freebsd4.4/js/src/xpconnect/to
ols/src:
 makensXPCToolsCompiler.cpp
c++ -o nsXPCToolsCompiler.o -c -DOSTYPE=\"FreeBSD4\" -DOSARCH=\"FreeBSD\"
-DMOZ_REFLOW_PERF -DMOZ_REFLOW_PERF_DSP -DOJI -DJSFILE -DJS_THREADSAFE  
-I../../../../../dist/include -I../../../../../dist/include
-I/home/timeless/mozilla/obj-gtk-i386-unknown-freebsd4.4/dist/include/nspr     
-I/usr/X11R6/include   -fPIC  -I/usr/X11R6/include -fno-rtti -fno-exceptions
-Wall -Wconversion -Wpointer-arith -Wbad-function-cast -Wcast-align
-Woverloaded-virtual -Wsynth -pedantic -Wno-long-long -pipe -pthread  -DDEBUG
-DDEBUG_timeless -DTRACING -g -I/usr/X11R6/include -DMOZILLA_CLIENT -include
../../../../../config-defs.h -Wp,-MD,.deps/nsXPCToolsCompiler.pp
/home/timeless/mozilla/js/src/xpconnect/tools/src/nsXPCToolsCompiler.cpp
In file included from 
/home/timeless/mozilla/js/src/xpconnect/tools/src/nsXPCToolsCompiler.cpp:38:
/home/timeless/mozilla/js/src/xpconnect/tools/src/xpctools_private.h:126: macro 
`JSLL_NEG' used with too many (3) args
/home/timeless/mozilla/js/src/xpconnect/tools/src/xpctools_private.h:124: end 
of file read inside definition
/home/timeless/mozilla/js/src/xpconnect/tools/src/nsXPCToolsCompiler.cpp:159:
syntax error at end of input
gmake: *** [nsXPCToolsCompiler.o] Error 1

This is more of a correctness issue for the moment, because as we run into OS's 
that don't build we're just throwing the JS_HAVE_LONG_LONG switch... <q 
class="ot"> at some point i'll probably ask about autoconf or something so i 
don't need to keep adding *BSD entries</q>
Time to autoconfig this macro?

/be
Assignee: rogerl → khanson

Updated

17 years ago
Target Milestone: --- → Future
(Assignee)

Comment 2

16 years ago
well, this is funny. 18months to the day.
anyway, i was looking at this yesterday and i figured out the problem.

dbradley and i had talked about it a few months back when i was fixing JSNow for
y2038 and it failed to build on one of my compilers (openwatcom or digitalmars),
the problem is that *LL_INIT() may only be used as an initializer. dbradley
mentioned that there was an instance in xpconnect which would probably cause a
problem, it turns out that it was this instance.

the fix is easy, i've tested it on msvc6 w32 with and without HAVE_LONG_LONG, it
compiles. (but i didn't build a full tree so it didn't link)

for people interested in testing w/o have_long_long you'll need to twiddle
dist/include/nspr/prcpucfg.h
Assignee: khanson → timeless
Component: JavaScript Engine → XPConnect
OS: other → FreeBSD
Summary: !JS_HAVE_LONG_LONG fallback doesn't work @ nsXPCToolsCompiler.cpp > xpctools_private.h > jslong.h → nsXPCToolsCompiler.cpp > xpctools_private.h incorrectly uses LL_INIT which breaks for !*HAVE_LONG_LONG
Target Milestone: Future → ---
(Assignee)

Comment 3

16 years ago
Created attachment 118186 [details] [diff] [review]
use LL_INIT correctly so that platforms without HAVE_LONG_LONG don't carp
(Assignee)

Updated

16 years ago
Attachment #118186 - Flags: review?(dbradley)

Comment 4

16 years ago
Comment on attachment 118186 [details] [diff] [review]
use LL_INIT correctly so that platforms without HAVE_LONG_LONG don't carp

r=dbradley

You can remove the jslong.h include
Attachment #118186 - Flags: review?(dbradley) → review+

Comment 5

16 years ago
timeless: do we still need to support any compiler that doesn't
have long long or an equivalent 64-bit integer type?
(Assignee)

Comment 6

16 years ago
Comment on attachment 118186 [details] [diff] [review]
use LL_INIT correctly so that platforms without HAVE_LONG_LONG don't carp

we intend to support embedding platforms which will have that restriction
Attachment #118186 - Flags: superreview?(dmose)

Comment 7

16 years ago
Comment on attachment 118186 [details] [diff] [review]
use LL_INIT correctly so that platforms without HAVE_LONG_LONG don't carp

sr=dmose@mozilla.org
Attachment #118186 - Flags: superreview?(dmose) → superreview+
(Assignee)

Comment 8

16 years ago
checked in (and jslong.h removed per dbradley since it is no longer used).
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 9

16 years ago
It is important for me to know that there really are compilers
that don't have long long (or a 64-bit integer type) that we
need to support.

Recently I have started to tell people that it is no longer
necessary to use NSPR's LL_ macros when writing new code.  The
reasons are:
1. HAVE_LONG_LONG is defined for all the compilers that NSPR
currently supports.  (See the mozilla/nsprpub/pr/include/md/*.cfg
files.)
2. The 1999 revision of the C Standard (also known as C99) added
the long long int type.  I expect that long long will be
universally supported by compilers very soon.

Could Brendan or mozilla.org's language and porting exports decide
whether there is a need to support compilers that don't have
long long or a 64-bit integer type?  My recommendation is that it
is not necessary, but I'd like to hear your expert opinions.

Comment 10

16 years ago
Checkin verified; including removal of #include "jslong.h" 
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.