Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Lynn McGuire 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: References: 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: Content-Language: en-US Bytes: 5545 On 10/26/2024 6:51 AM, Thomas Koenig wrote: > Lynn McGuire schrieb: >> On 10/24/2024 1:28 AM, Thomas Koenig wrote: >>> Lynn McGuire 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