Re: Is there a way in Fortran to designate an integer value as integer*8 ?

On 10/26/2024 6:51 AM, Thomas Koenig wrote:

Lynn McGuire <lynnmcguire5@gmail.com> schrieb:

On 10/24/2024 1:28 AM, Thomas Koenig wrote:

Lynn McGuire <lynnmcguire5@gmail.com> schrieb:

 

F2C fixes the other big problem
automatically, the change of initial array index from one to zero.

>
If I remember correctly, it does so by issueing invalid C (or
C++), by using negative offsets from pointers.  Might work now,
might not work tomorrow.
>
But note the IIRC above.

>
I want to move to a monolanguage environment.  50,000 lines of my
calculation engine are C++ already.  850,000 lines to go.

 That motivation, I understand, especially if the GUI code is in C++,
but there is a caveat.  Consider
        subroutine foo(i,n)
       integer array(10)
       common array
       integer n
       integer i(n)
       integer k
       do k=1,n
          i(k) = k + array(k)
       end do
       end
 which gets translated by stock f2c (to which you may have made
adjustments) into
 #include "f2c.h"
 /* Common Block Declarations */
 struct {
     integer array[10];
} _BLNK__;
 #define _BLNK__1 _BLNK__
 /* Subroutine */ int foo_(integer *i__, integer *n)
{
     /* System generated locals */
     integer i__1;
      /* Local variables */
     static integer k;
      /* Parameter adjustments */
     --i__;
      /* Function Body */
     i__1 = *n;
     for (k = 1; k <= i__1; ++k) {
i__[k] = k + _BLNK__1.array[k - 1];
     }
     return 0;
} /* foo_ */
 The common block handling looks OK, but the dummy argument
(aka parameters, in C parlance) handling is very probably not.
 The "parameter adjustment" above is explicitly listed as undefined
behavior, in annex J2 of n2596.pdf (for example):
 "Addition or subtraction of a pointer into, or just beyond, an
array object and an integer type produces a result that does not
point into, or just beyond, the same array object (6.5.6)."
 Undefined behavior is the worst kind of error in your program
that you can have in C, it is not required to be diagnosed, and
compilers can, and do, make optimizations based on the assumption
that it does not happen, so this is liable to break in unforseen
circumstances.
 So if your version of f2c does the same, I would check the C++
standard if if has a similar provision (I strongly suspect so,
but I don't know), and, if that is the case, modify your version
of f2c to generate conforming code for array dummy arguments.
Otherwise, you are betting your company.

First, I include all of my 300+ common blocks as 200 files.  I converted those separately and cleaned them up so that the static variables and defines are easy to peruse and understand.  I delete all of the local common block conversions by f2c in the subroutines and change them back to include files.  An easy cleanup that I have to do 5,000 times (4,000 to go now plus the 100+ subroutines that we have modified for customers since I started the conversion project two years ago).
I also removed the parameter adjustments from my copy of f2c.  It is a little tricky but as you say, they are not legal code in C++.
I have extensively modified my copy of f2c so that it generates better legal C++ code and many other improvements.  But my changes are subject to the old 80 / 20 rule.  I have 80% automated conversions and 20% hand conversions.  I do have a little experience here: Fortran since 1975, C since 1987, and C++ since 2000.
Thanks for the warnings,
Lynn