Closed Bug 361267 Opened 18 years ago Closed 18 years ago

64 bit operations in libjs depend on hand maintained list of operating systems

Categories

(Core :: JavaScript Engine, defect)

x86
NetBSD
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 361268

People

(Reporter: pw-fb, Unassigned)

Details

User-Agent:       Mozilla/5.0 (X11; U; NetBSD i386; en-US; rv:1.9a1) Gecko/20051031 Firefox/1.6a1
Build Identifier: Mozilla/5.0 (X11; U; NetBSD i386; en-US; rv:1.9a1) Gecko/20051031 Firefox/1.6a1

libjs provides "Portable access to 64 bit numerics" via macros in
jslong.h which operate on types JS{,U}Int64 and JS{,U}int32 defined
in jstypes.h.  The definition of JS{,U}Int64 is based on whether
or not JS_HAVE_LONG_LONG is defined. JS_HAVE_LONG_LONG is defined
in jsosdep.h according to a manually maintained list of operating
systems. This list can't be accurate (e.g., Doesn't NetBSD have
64-bit datatypes? What about an ancient copy of said operating
system?), and the autoconf philosopy of testing for features rather
than OS names seems to be applicable in this case.

Before getting out the history books to write an autoconf 2.13
macro to test for long long and define JS_HAVE_LONG_LONG, is that
really the right thing to do?

To quote mozilla/configure.in:

  dnl pass -Wno-long-long to the compiler
  MOZ_ARG_ENABLE_BOOL(long-long-warning,
  [  --enable-long-long-warning
                            Warn about use of non-ANSI long long type],

So, do we really want (quoting jstypes.h)

  typedef long long JSInt64;
  typedef unsigned long long JSUint64;

? or rather

  typedef int64_t JSInt64
  typedef int32_t JSInt32

?

so write autoconf 2.13 equivalents of modern day autoconf's
 -- Macro: AC_TYPE_INT64_T
     If `stdint.h' or `inttypes.h' defines the type `int64_t', define
     `HAVE_INT64_T'.  Otherwise, define `int64_t' to a signed integer
     type that is exactly 64 bits wide and that uses two's complement
     representation, if such a type exists.
and
 -- Macro: AC_TYPE_UINT64_T

?

(We could in fact do all the types, so we would't need JS_BYTES_PER_x either,
and typedef int16_t JSInt16 etc is quite readable..)

Thoughts?

Cheers,

Patrick


Reproducible: Always

*** This bug has been marked as a duplicate of 361268 ***
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.