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)