From: cross@spitfire.i.gajendra.net
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.
>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.
You'd just add `-D_USE_STD_STAT` as an additional compiler
argument when building libgfortran, no?
- Dan C.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
