Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Lynn McGuire <lynnmcguire5@gmail.com>
Newsgroups: comp.lang.fortran
Subject: Re: Is there a way in Fortran to designate an integer value as
 integer*8 ?
Date: Sat, 26 Oct 2024 15:50:28 -0500
Organization: A noiseless patient Spider
Lines: 105
Message-ID: <vfjkml$3sd4e$1@dont-email.me>
References: <vdict2$339ak$1@dont-email.me> <vdir24$35104$1@dont-email.me>
 <vdk718$3bulb$1@dont-email.me> <vdl6fi$3jra3$2@dont-email.me>
 <vdlfpl$3l0f5$1@dont-email.me> <vdmbml$3p2dv$1@dont-email.me>
 <vdmrgc$3rih7$2@dont-email.me> <vdn4kp$3ssv4$9@dont-email.me>
 <vdn4ul$3t78e$3@dont-email.me> <vdn659$3ssv4$18@dont-email.me>
 <vdnrr9$3qrq$1@dont-email.me> <vdnvgh$49ai$1@dont-email.me>
 <vdqe7n$kqq0$1@dont-email.me> <vdqmue$lo51$11@dont-email.me>
 <vds64m$sj9s$1@dont-email.me> <vf2507$9mo4$2@dont-email.me>
 <vf4mbh$qfqu$1@dont-email.me> <vf4pi2$qsfn$1@dont-email.me>
 <vf7but$1blh6$1@dont-email.me> <vf98hi$1lsqn$2@dont-email.me>
 <vfbgtf$25j82$1@dont-email.me> <vfbno9$28v56$3@dont-email.me>
 <vfbqt2$29fb2$1@dont-email.me> <vfcpei$2hhb3$1@dont-email.me>
 <vfhggd$3digo$1@dont-email.me> <vfil4e$3n2b6$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 26 Oct 2024 22:50:30 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="86228b32b1035bca6a595e52e11030d1";
	logging-data="4076686"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+jjhisTiTXALrEGdaK408+BDWqlH9qEog="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:cj8sHVRnObvaloz+tDSf7iHeY1Y=
In-Reply-To: <vfil4e$3n2b6$1@dont-email.me>
Content-Language: en-US
Bytes: 5545

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