From Newsgroup: comp.lang.fortran
In comp.lang.c James Kuyper <
jameskuyper@alumni.caltech.edu> wrote:
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.
There is more context to this: AFAICS the relevant use case is
handling Fortran/f2c calling convention where on entry to the function
the pointer points to first element of Fortran array. This element
has index 1 in Fortran but would have index 0 in generated C code.
f2c wanted to use the same indices as in Fortran, so is doing "adjustment".
But the resulting base pointer points one element before array,
so in normal use 6.5.6 applies.
In effect, in this case Lawrence is making noise but the other
folks are correct.
--
Waldek Hebisch
--- Synchronet 3.20a-Linux NewsLink 1.114