XPost: comp.lang.c   
   From: antispam@fricas.org   
      
   In comp.lang.c James Kuyper  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  schrieb:   
   >>>>   
   >>>> On Sat, 26 Oct 2024 21:38:38 -0000 (UTC), Thomas Koenig wrote:   
   >>>>   
   >>>>> Lawrence D'Oliveiro  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   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)