search

Perl / perl5

🐪 The Perl programming language
https://dev.perl.org/perl5/
Other
1.85k stars 527 forks source link

Suggestions for 64bit /ANSI C compatibility #508

Closed p5pRT closed 20 years ago

p5pRT commented 24 years ago

Migrated from rt.perl.org#1354 (status was 'resolved')

Searchable as RT1354$

p5pRT commented 24 years ago

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

p5pRT commented 24 years ago

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.

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

In article \199909122338\.JAA04048@&#8203;trout\.hpc\.CSIRO\.AU\, "Len Makin\, CSIRO Maths & Info Sci\, Melbourne." \len@&#8203;hpc\.CSIRO\.AU writes​:

On Friday\, 10 September 1999\, at 7​:55\, Tom Hughes \tom@&#8203;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.