Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: James Kuyper <jameskuyper@alumni.caltech.edu>
Newsgroups: comp.lang.fortran,comp.lang.c
Subject: Re: Is there a way in Fortran to designate an integer value as
 integer*8 ?
Date: Tue, 29 Oct 2024 14:11:42 -0400
Organization: A noiseless patient Spider
Lines: 87
Message-ID: <vfr8gv$1l4gd$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>
 <vfjj4h$3s32a$2@dont-email.me> <vfjngu$3spno$1@dont-email.me>
 <vfk6im$3utgd$2@dont-email.me> <vfks8r$6vrt$1@dont-email.me>
 <vfm9nj$jekn$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 29 Oct 2024 19:11:43 +0100 (CET)
Injection-Info: dont-email.me; posting-host="e2fb6cc61d208436c858d7af28448726";
	logging-data="1741325"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/Cum3QQD6Qw2NAFIXnk9/FW3sSs7AgeL4="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:LcFanoR946kN5OtIBM+b38ztKVM=
In-Reply-To: <vfm9nj$jekn$2@dont-email.me>
Content-Language: en-US
Bytes: 5465

On 10/27/24 17:01, Lawrence D'Oliveiro wrote:
> On Sun, 27 Oct 2024 08:05:47 -0000 (UTC), Thomas Koenig wrote:
> 
>> Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:
>>>
>>> On Sat, 26 Oct 2024 21:38:38 -0000 (UTC), Thomas Koenig wrote:
>>>
>>>> Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:
>>>>
>>>>> On Sat, 26 Oct 2024 11:51:42 -0000 (UTC), Thomas Koenig wrote:

Lawrence snipped the following extremely relevant text from his
response, which made it very unclear what the controversy was about.

>>>>>> #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)."
[snipped ensuing conversation, which contained nothing of value.]

It would be more appropriate to cite 6.5.6 itself, rather than Annex J2,
which is just a summary. The summary often doesn't go into as much
detail as the clause being summarized, and the details that are left out
of the summary are occasionally relevant.
It would also be better to cite a newer version of the standard. The
latest I have is n3096, dated 2023-04-01 (but it's not an April Fool's
joke), and in that version 6.5.6p10 says:

"If the pointer operand and the result do not point to elements of the
same array object or one past the last element of the array object, the
behavior is undefined."

However, there was equivalent wording in all previous versions of the C
standard, so it doesn't really matter which version you look at.

As far as C is concerned, whether or not the adjustment had undefined
behavior depends entirely upon where i__ points when foo_() is called.
If it points at any location in an array other than the first element of
the array (including one past the end of the array), then --i__ is
perfectly legal, because the result will point at an earlier element of
the same array. For instance, this would be perfectly legal:

	integer array[11]={0};
        int ret = foo_(array + 1, 10);

I've seen code like this used to make C code look more like the Fortran
it was translated from, and in that context a function like this would
be called with a pointer to the first element of an array, in which case
the behavior is indeed undefined, which is why that's a bad way to
handle the translation. But it's the combination of foo_()'s definition,
and how it is called, that make the behavior undefined, not just the
code of foo_() itself.