Hi Steve,
On 6/11/25 23:06, Steve Kargl wrote:
On Wed, Jun 11, 2025 at 10:18:37PM +0200, Harald Anlauf wrote:
- for the INTEGER(KIND=4) versions the STATUS returns ERANGE if
an overflow is encountered.
The latter is certainly debatable, as one of the existing testcases
stat_{1,2}.f90 may fail on systems where e.g. an inode number is larger
than INT32_MAX may occur. Options are to drop the overflow check, or
to run those testcases with additional option -fdefault-integer-8.
Opinions?
another option is:
- return -1 for components which overflow, and not return ERANGE,
thus to leave it up to the user to handle this
It is arguably not an error generated by stat(3), but by the
interface to Fortran in the runtime.
Thanks for doing these types of cleanups.
You may want to take a peek at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30372
where I posted a few cleanups for SLEEP, UMASK, UNLINK,
etc. In those cleanups, I would cast arguments to
integer(4) if I could (ie., if I know the arg was in range)
to prevent an explosion in the size of libgfortran.
I do not plan to implement any new library versions. The
*_i4 and *_i8 versions are already available. All integer
arguments should be kind=4 or 8, and needed conversions
can be done using scalar temporaries.
I'll need to think about your -fdefault-integer-8 question
for a bit. Because that option exists and can change
default integer kind, we'll need *_i4 and *_i8 versions of
the functions in libgfortran. I suspect we'll need to
run the testcases with -fdefault-integer-8.
This depends on the way we handle overflow. The variant
above would not need this option.
If no one approves your patch by Saturday, I'll review.
Any helpful feedback is greatly appreciated.
Thanks
Harald
