From len@hpc.CSIRO.AU

  _unix Defined as the decimal constant 1

  _SX Defined as the decimal constant 1.

  unix Defined as the decimal constant 1. This is not defined in the
  ANSI strictly conforming mode.

  SX Defined as the decimal constant 1. This is not defined in the
  ANSI strictly conforming mode.
  SX Defined as the decimal constant 1. This is not defined in the
  ANSI strictly conforming mode.

  _FLOAT0 Defined as the decimal constant 1 in float0 mode, but is not
  defined as a macro name in other float modes.

  _FLOAT1 Defined as the decimal constant 1 in float1 mode, but is not
  defined as a macro name in other float modes.

  _FLOAT2 Defined as the decimal constant 1 in float2 mode, but is not
  defined as a macro name in other float modes

  _INT64 Defined as the decimal constant 1 in float2-int64 mode, but
  is not defined as a macro name in other float modes.

  _LONG64 Defined as the decimal constant 1 in float0 and
  float2-int64 mode, but is not defined as a macro name in
  other float modes.
So wherever you have #ifdef/ifndef cray or convex, you should also have
#ifdef _SX for completeness.
More later if I get time...
Cheers,
  Len
Len.Makin@​cmis.csiro.au​:+61 3 9669 8109​: CSIRO/Bureau of Meteorology
  High Performance Computing and Communications Centre
  24th floor, 150 Lonsdale St., Melbourne 3000, Victoria, AUSTRALIA

From [Unknown Contact. See original ticket]

In message <199909100017.KAA22447@​trout.hpc.CSIRO.AU> you wrote​:

I noticed the following (potential problems?) which you may choose to
ignore. The main one is that ANSI C does not guarantee portability for
(a-b) where a and b are pointers. Such expressions should be cast to, or
type compatible with, ptrdiff_t (from <stddef.h>)

Not true I'm afraid. ISO C does allow you to subtract one pointer
from another so long as they are both pointers of the same type and
both point to the same object. The result of such a subtraction is
of type ptrdiff_t.

Beyond that there are no guarantees and certainly none that casting
a pointer to ptrdiff_t helps in any way. That doesn't even make
logical sense as that type is defined to represent the different
between two pointers, not a pointer.

On the Cray, as you probably know, it will work OK for pointers apart
from char* . Cray char* is a word address in the LS(right) end, and a
byte offset in the MS(left) end. Treating as an int, and especially
doing subtraction, is risky business.

If you have two char pointers into the same string or array of char
and subtracting one from the other does not produce the correct
answer then that is not an ISO C compliant implementation.

Tom

--
Tom Hughes (tom@​compton.nu)
http​://www.compton.nu/
...I have a firm grip on reality. Now I can strangle it.

From [Unknown Contact. See original ticket]

In article <199909122338.JAA04048@​trout.hpc.CSIRO.AU>, "Len Makin, CSIRO Maths & Info Sci, Melbourne." <len@​hpc.CSIRO.AU> writes​:

On Friday, 10 September 1999, at 7​:55,
Tom Hughes <tom@​compton.nu> wrote​:

Not true I'm afraid. ISO C does allow you to subtract one pointer
from another so long as they are both pointers of the same type and
both point to the same object. The result of such a subtraction is
of type ptrdiff_t.

Yes, I agree. Only problem is that some think it is int.

A reasonable guess on most platforms of course given that the standard
requires ptrdiff_t to be a signed integer type. It may be broken though
on platforms where long is wider than int though.

Beyond that there are no guarantees and certainly none that casting
a pointer to ptrdiff_t helps in any way. That doesn't even make
logical sense as that type is defined to represent the different
between two pointers, not a pointer.

You will note however that I was not advocating casting the pointers,
but the difference(a-b), which I agree the compiler SHOULD cope with.

It seems I misread what you were saying... In which case you're probably
right that perl needs changing.

Tom

--
Tom Hughes (tom@​compton.nu)
http​://www.compton.nu/
... I didn't know it was impossible when I did it.