Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Thomas Koenig <tkoenig@netcologne.de>
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 11:51:42 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 83
Message-ID: <vfil4e$3n2b6$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>
Injection-Date: Sat, 26 Oct 2024 13:51:43 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="912f28b02a1992e4d280981567106b3c";
	logging-data="3901798"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19x2p4aLN7/JQyFQFgM+/SSqeUUojlz8jY="
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:je/l6s+CMw1TzOUejUyE+62j9gQ=
Bytes: 4120

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.