From: cross@spitfire.i.gajendra.net   
      
   In article <109k6sf$3v9m4$1@paganini.bofh.team>,   
   Waldek Hebisch  wrote:   
   >As I wrote I am trying to compile gcc-15 cross-compiler targeting   
   >VMS.  I now have trouble with libgfortran.  Namely libgfortran   
   >tries to use Posix compatiblity to perform some file operations.   
   >I have trouble with st_ino filed in 'struct stat'.  Code below   
   >ilustrates the problem.  I am getting warning from VMS C compiler:   
   >   
   >    mp->st_ino = sb.st_ino;   
   >....^   
   >%CC-W-CVTDIFTYPES, In this statement, "sb.st_ino" of type "pointer to   
   unsigned s   
   >hort", is being converted to "unsigned short".   
   >   
   >   
   >    mp->st_ino = sb.st_ino;   
   >.................^   
   >%CC-W-MAYLOSEDATA, In this statement, "sb.st_ino" has a larger data size than   
   "u   
   >nsigned short".  Assignment can result in data loss.   
   >   
   >While this is only a warning in VMS C, such thing may indicate serious   
   >problem.  Also, I tried to print 'sizeof(sb.st_ino)' and   
   >'sizeof(unsigned short *)'.  The results are 6 and 4 respecitvely.   
   >So size of type reported above does not match with size of 'sb.st_ino'.   
      
   The error message above is saying that `sb.st_ino` is a pointer;   
   specifically, it's a `unsigned short *`, and that you're trying   
   to assign it to an unsigned short without indirecting.  One   
   wonders what, `mp->st_ino = *sb.st_ino;` would do?   
      
   This doesn't look right to me, though.  Clearly, file structures   
   on VMS do not have an "inode" in the same way that most of them   
   do on Unix, but if the field exists in the struct, it would.   
      
   Looking on Eisner, I see this:   
      
   ```   
   $ search *.h ino_t   
      
   ******************************   
   SYS$COMMON:[DECC$LIB.REFERENCE.DECC$RTLDEF]DECC$TYPES.H;2   
      
       typedef unsigned short __ino_t;   
      
   ******************************   
   SYS$COMMON:[DECC$LIB.REFERENCE.DECC$RTLDEF]DIRENT.H;2   
      
   **  The type ino_t is an _XOPEN_SOURCE extension.   
   #   ifndef  __INO_T   
   #       define __INO_T   
           typedef __ino_t ino_t;   
           __ino_t d_ino[3];           /*  file serial number (vms-style inode) */   
      
   ******************************   
   SYS$COMMON:[DECC$LIB.REFERENCE.DECC$RTLDEF]STAT.H;2   
      
   #   ifndef __INO_T   
   #       define __INO_T 1   
           typedef __ino_t ino_t;   
           __ino_t      st_ino[3];       /* 3 words to receive fid */   
      
   ******************************   
   SYS$COMMON:[DECC$LIB.REFERENCE.DECC$RTLDEF]TYPES.H;2   
      
   #if !defined __INO_T  && !defined _DECC_V4_SOURCE   
   #   define __INO_T 1   
       typedef __ino_t ino_t;   
   $   
   ```   
      
   So `st_ino` is really an _array_; note again the error message,   
   which just tells you the type that the compiler is working with   
   in the context of this assignment: that pointer type is due to C   
   making unadorned array accesses decay into pointers (an   
   historical artifact from the B language, where the `[]` syntax   
   was used for pointers as well as arrays), so the compiler turned   
   `.st_ino` into a pointer for this access and then complained   
   that you were assigning its value to an `unsigned short`.   
      
   >I am worried by this.  And of course important question is if   
   >'stat' works as described in Posix?  I did not check Posix spec,   
   >but I would expect that ino_t is supposed to be type of 'st_ino'   
   >field of of 'struct stat', which apparently fails on VMS.   
      
   It is.  But on VMS, that type is an array, not a scalar.   
      
   However, POSIX mandates that `ino_t` is defined as an unsigned   
   integer type in `sys/types.h`, so VMS violates POSIX in this   
   regard.   
   (https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/sys_types.h.html)   
      
   >And fundamental thing: Posix promises that two files are in   
   >fact the same file if and only if both 'st_dev' field and   
   >'st_ino' fields match.  And libgfortran depends on this.   
   >Does it hold on VMS?   
      
   In what way does libgfortran really depend on that?   
      
   Perhaps start by building just C/C++ and skip Fortran for now?   
      
   	- Dan C   
      
      
   >-------------------------------------   
   >#include    
   >typedef struct   
   >{   
   >  /* Cached stat(2) values.  */   
   >  dev_t st_dev;   
   >  ino_t st_ino;   
   >  long long file_size;   
   >}   
   >my_sb;   
   >   
   >int   
   >my_stat(const char * name, my_sb * mp) {   
   >    struct stat sb;   
   >    int res = stat(name, &sb);   
   >    mp->st_dev = sb.st_dev;   
   >    mp->st_ino = sb.st_ino;   
   >    mp->file_size = sb.st_size;   
   >    return res;   
   >}   
   >------------------------------   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)