[Nexus-developers] NeXus-64 bit

[Przemek Klosowski]

    I now got 64 bit integers working for NeXus for HDF-5 and XML. It
    required changes to several bindings too. And we are entering a
    ball of mud:

    Contrary to my expectations I had to notice that a long on an
    Intel-PC is 32bit only and not 64bit.  On an alpha a long is
    sufficient to get a 64 bit integer.  It would be interesting to
    test this on a 64-bit Intel, but I have none available. In order
    to get a 64 bit integer on 32 bit Intel you need a long long
    type. But long long is C99 standard. As this is not yet 50 years
    old, there might be

That is odd, because on my x86_64 platform with default gcc 4.0.2
I get C8 S16 I32 L64 F32 D64 LD128 P64 (see below).

I believe that in that environment, 'long long' has identical length,
structure and alignment properties as 'long', based on a quick hack to
'showconfig' I just did.

	 p


Produced by config version 4.2, CWI, Amsterdam
Compiler claims to be ANSI C level 1

Char = 8 bits, signed
Short=16 int=32 long=64 float=32 double=64 bits
Long double=128 bits
Char pointers = 64 bits BEWARE! larger than int!
Int pointers = 64 bits BEWARE! larger than int!
Alignments used for char=1 short=2 int=4 long=8
Character order:
    short: BA
    int:   DCBA
    long:  HGFEDCBA
Strings are shared
Overflow of a short does not generate a trap
Maximum short = 32767 (= 2**15-1)n
Minimum short = -32768
Overflow of an int does not generate a trap
Maximum int = 2147483647 (= 2**31-1)
Minimum int = -2147483648
Overflow of a long does not generate a trap
Maximum long = 9223372036854775807 (= 2**63-1)
Minimum long = -9223372036854775808
Maximum unsigned short = 65535
Maximum unsigned int = 4294967295
Maximum unsigned long = 18446744073709551615

PROPERTIES OF FLOAT:
Base = 2
Significant base digits = 24 (= at least 6 decimal digits)
Arithmetic rounds towards nearest
   Tie breaking rounds to even
Smallest x such that 1.0-base**x != 1.0 = -24
Smallest x such that 1.0-x != 1.0 = 2.98023224e-08
Smallest x such that 1.0+base**x != 1.0 = -23
Smallest x such that 1.0+x != 1.0 = 5.96046519e-08
Number of bits used for exponent = 8
Minimum normalised exponent = -125
Minimum normalised positive number = 1.17549435e-38
The smallest numbers are not kept normalised
Smallest unnormalised positive number = 1.40129846e-45
There is an 'infinite' value
Maximum exponent = 128
Maximum number = 3.40282347e+38
Arithmetic uses a hidden bit
It looks like single length IEEE format

PROPERTIES OF DOUBLE:
Base = 2
Significant base digits = 53 (= at least 15 decimal digits)
Arithmetic rounds towards nearest
   Tie breaking rounds to even
Smallest x such that 1.0-base**x != 1.0 = -53
Smallest x such that 1.0-x != 1.0 = 5.5511151231257827e-17
Smallest x such that 1.0+base**x != 1.0 = -52
Smallest x such that 1.0+x != 1.0 = 1.1102230246251568e-16
Number of bits used for exponent = 11
Minimum normalised exponent = -1021
Minimum normalised positive number = 2.2250738585072014e-308
The smallest numbers are not kept normalised
Smallest unnormalised positive number = 4.9406564584124654e-324
There is an 'infinite' value
Maximum exponent = 1024
Maximum number = 1.7976931348623157e+308
Arithmetic uses a hidden bit
It looks like double length IEEE format

PROPERTIES OF LONG DOUBLE:
Base = 2
Significant base digits = 64 (= at least 18 decimal digits)
Arithmetic rounds towards nearest
   Tie breaking rounds to even
Smallest x such that 1.0-base**x != 1.0 = -64
Smallest x such that 1.0-x != 1.0 = 2.71050543121376108502e-20
Smallest x such that 1.0+base**x != 1.0 = -63
Smallest x such that 1.0+x != 1.0 = 5.42101086242752217063e-20
Number of bits used for exponent = 15
Minimum normalised exponent = -16381
Minimum normalised positive number = 3.36210314311209350626e-4932
The smallest numbers are not kept normalised
Smallest unnormalised positive number = 3.64519953188247460253e-4951
There is an 'infinite' value
Maximum exponent = 16384
Maximum number = 1.18973149535723176502e+4932

*** Something fishy here!
    Exponent size + mantissa size doesn't match with the size of a long double!

It doesn't look like IEEE format

Float expressions are evaluated in float precision
Double expressions are evaluated in double precision
Long double expressions are evaluated in long double precision