From: arne@vajhoej.dk   
      
   On 9/9/2025 12:26 PM, Dan Cross wrote:   
   > In article <109o21i$g12m$1@paganini.bofh.team>,   
   > Waldek Hebisch  wrote:   
   >> Craig A. Berry  wrote:   
   >>> On 9/7/25 1:17 PM, Waldek Hebisch wrote:   
   >>>> [snip]   
   >>>> Yes, I st_ino on VMS is an array.  I have now modified libgfortran   
   >>>> to accomodate this.   
   >>>   
   >>> Yes and no.  If you insist on using decades-old VAX C compatibility   
   >>> features, then st_ino is an array.  Probably because you couldn't fit 3   
   >>> words into any integral type on VAX.   
   >>>   
   >>> If you define _USE_STD_STAT, though, then you get:   
   >>>   
   >>> typedef unsigned __int64    __ino_t;   
   >>> typedef __ino_t ino_t;   
   >>>   
   >>> You also get large file support, which you could get independently via   
   >>> _LARGEFILE if for some reason you had to.  You definitely want   
   >>> _USE_STD_STAT for anything new and/or cross-platform.  That gets you   
   >>> something that was POSIX-compliant a decade or two ago. It isn't   
   >>> compliant now because the file times are still just ints rather than   
   >>> structs with high-precision components as newer POSIX requires.   
   >>   
   >> Well, the contex is libgfortran, part of Fortran compiler.  It is   
   >> supposed to work with 60 years old Fortran code.  Such code may need   
   >> compatiblity features.   
   >   
   > This gets back to my original question: not all code in   
   > libgfortran is created the same.  I doubt that 60-year old code   
   > cares about doing inode number+device equality to determine   
   > uniqueness of a file on a Unix system...particularly as Unix did   
   > not exist 60 years ago.   
   >   
   > Some code _may_ need that.  My guess is that 99.99% wouldn't   
   > care and you can hack it for now to make forward progress.   
      
   I suspect it is a standard compliance thing.   
      
   Fortran 77 standard says about open:   
      
      
   If the file to be connected to the unit is not the same as the file to   
   which the unit is   
   connected, the effect is as if a CLOSE statement (12.10.2) without a   
   STATUS= specifier   
   had been executed for the unit immediately prior to the execution of the   
   OPEN statement.   
   If the file to be connected to the unit is the same as the file to which   
   the unit is connected,   
   only the BLANK= specifier may have a value different from the one   
   currently in effect.   
   Execution of the OPEN statement causes the new value of the BLANK=   
   specifier to be in   
   effect. The position of the file is unaffected.   
      
      
   Fortran 2018 standard says practically the same just with   
   more words.   
      
   Demo on VMS:   
      
   $ type f1.txt   
   1   
   2   
   3   
   $ type f2.txt   
   1   
   2   
   3   
   $ type f.for   
          program f   
          character*80 line   
          open(unit=1,file='f1.txt',status='old')   
          read(unit=1,fmt=*) line   
          write(*,*) line   
          open(unit=1,file='f1.txt',status='old')   
          read(unit=1,fmt=*) line   
          write(*,*) line   
          open(unit=1,file='f2.txt',status='old')   
          read(unit=1,fmt=*) line   
          write(*,*) line   
          end   
   $ for f   
   $ link f   
   $ run f   
   1   
   2   
   1   
      
   It also works with GFortran.   
      
   One can say that the code is pretty hopeless, but standard   
   compliance is a real thing.   
      
   Arne   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)