From: antispam@fricas.org

Craig A. Berry  wrote:
> On 9/7/25 1:17 PM, 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/s
s_types.h.html)
>>
>> 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.

ATM I did not look if/how gcc supports such switches.  This is
certainly thing to look at later, but now I want old stuff to
work, when this works I can look at newer things.

>>>> 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?
> If st_ino is an integral type, then I think the answer is yes.  If it's
> the array type, then it probably depends on who's doing the comparisons.
> If you pass the stat structure to existing code that does the
> comparison, it may or may not handle the array correctly.
>
> Perl has bent over backwards to try to get around this very ino_t problem:
>
> 
>
> I'm not saying you want to do the same thing (in fact really hope you
> don't) but the comments there may illustrate the mess you have to wade
> through if you try to avoid using a slightly more modern stat struct.
>
>

--
                              Waldek Hebisch

--- SoupGate-Win32 v1.05
 * Origin: you cannot sedate... all the things you hate (1:229/2)