From: cross@spitfire.i.gajendra.net   
      
   In article <109ki70$2fj$1@paganini.bofh.team>,   
   Waldek Hebisch  wrote:   
   >Dan Cross  wrote:   
   >> 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)   
   >   
   >Yes, I st_ino on VMS is an array.  I have now modified libgfortran   
   >to accomodate this.   
   >   
   >>>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?   
   >   
   >libgfortran has function which should determine if two files   
   >are in fact the same file.  And it uses Posix features,   
   >except for MinGW where thay use MinGW-specific method.   
   >If that Posix feature fail, then correspondig function in   
   >libgfortran will not work correctly.   
      
   Given that there is precedent for specific platforms in that   
   code, why not make a VMS-specific variant?   
      
   >> Perhaps start by building just C/C++ and skip Fortran for now?   
   >   
   >Well, C builds OK (I need to do extra work so that generated   
   >binares have chance of working on VMS).  C++ build waits for   
   >resolution of binutils problems (only gas problem is critical to   
   >build but probably it will be resolved only after other binutils   
   >problems are resolved).  Ada hits trouble very early (could be   
   >because host has gcc/GNAT 12).  So Fortran is natural place   
   >to make progress.   
      
   Ok.  I'd bias towards getting C executables working first, but I   
   am not the one swinging the hammer here.   
      
   	- Dan C.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)