chsort@ in 64-bit programs

I noticed that chsort@ behaves differently in 32-bit and 64-bit programs, when the last argument is negative. It is ignored in 32-bit, but causes run time error in a 64-bit program.

PROGRAM CHSORT_TEST
   IMPLICIT NONE
      
   INTEGER :: arr(100),N
   CHARACTER*5 :: SORT(100)
   
   WRITE (*,*) 'Start'
   
   N = -1
   call chsort@ (sort,arr,N)
 
   WRITE (*,*) 'END'
END

Your code does not issue a correct call to the FTN95 routine CHSORT@.

1. The second argument should be a character array with N elements. Your code has a scalar character variable.

2. The third argument should be the number of array elements that are to be sorted. It makes no sense to use -1 for this count, as your code does.

When a function is called with incorrect arguments, the behaviour of the program is 'undefined', so what the incorrect code does in 32-bit versus 64-bit EXEs is of little to no interest.

This may help:

program test_chsort
implicit none
character(len=8):: sname(1:9) = ['Smith   ','Jones   ','Taylor  ',&
                                 'Brown   ','Williams','Wilson  ',&
                                 'Watson  ','Walker  ','Walton  ']
integer :: a(1:9)
integer :: n=9
integer :: i
  call chsort@(a,sname,n)
  do i = 1, n
    print*, i, ' ', sname(a(i))
  end do
end program test_chsort

Returns

            1 Brown
            2 Jones
            3 Smith
            4 Taylor
            5 Walker
            6 Walton
            7 Watson
            8 Williams
            9 Wilson

Quoted from mecej4 Your code does not issue a correct call to the FTN95 routine CHSORT@.

1. The second argument should be a character array with N elements. Your code has a scalar character variable.

2. The third argument should be the number of array elements that are to be sorted. It makes no sense to use -1 for this count, as your code does.

When a function is called with incorrect arguments, the behaviour of the program is 'undefined', so what the incorrect code does in 32-bit versus 64-bit EXEs is of little to no interest.

Thanks for the comment. The first argument has been modified. You are also right about the second point. This value is however set from other codes. I just made it simple for this sample code.

I just meant, that it would be a positive point, if even for 'undefined' situations, both 32-bit and 64-bit behave similarly as it is the case for many other situations, like:

      N = -1
      DO I = 1, N
        WRITE (*,*) I
      END DO

Please note that the four lines of code that you showed as an example of 'an undefined situation' has nothing undefined about its expected behaviour. When N = -1, the subsequent DO loop is not executed at all, so the four lines of code are equivalent to just one line:

N = -1

Execution of this single statement is not expected to show any difference for 32-bit or 64-bit compilation.