On Tue, Jun 17, 2025 at 12:05:34PM +0300, Janne Blomqvist wrote: > On Mon, Jun 16, 2025 at 9:41 PM Harald Anlauf <anl...@gmx.de> wrote: > > > > Am 16.06.25 um 02:18 schrieb Steve Kargl: > > > Harald, > > > > > > I did a quick glance at the patch and did not see anything that > > > jumped out as needing a change. OK to commit. > > > > > > Earlier today I came to the same conclusion that -1 on overflow is > > > probably the right thing to do. Gfortran would need a way to > > > supply the value of ERANGE (on all supported targets) so a > > > user can write a test. Yes, POSIX seems to define ERANGE as > > > 34, but is that guaranteed on non-POSIX targets? > > > > > After thinking some more, I am struggling with these issues: > > > > - ERANGE may not be defined, and the value of ERANGE may not > > be portable between targets. How to handle that on the > > Fortran side? > > intrinsics/getcwd.c uses ERANGE unconditionally, so it seems all > targets that GFortran supports do define ERANGE. As for the value, > POSIX does not specify numerical values that the errno constants > should take, though it seems 34 is more or less universal on Unix > systems. Also it seems windows uses 34. I'd say just use ERANGE if > appropriate, and if some target defines it differently then it's up to > the user to deal with it.
I think your last sentence is the problem with returning ERANGE. If gfortran returns ERANGE, then gfortran should also have a facility that a user can query for the actual value. Walt mentions PXF in another reply. I have a copy of IEEE Std 1003.9-1992 (aka POSIX FORTRAN77 Language Interface - Part 1). I never found the time to implement (parts of) it. It should also be noted that on FreeBSD (and likely other UNIX-like systems), one finds % man 2 stat ... RETURN VALUES Upon successful completion, the value 0 is returned; otherwise the value -1 is returned and the global variable errno is set to indicate the error. Note, ERANGE is not documented as a value to which errno can be set. > > - my initial proposal to return ERANGE has the potentially confusing > > effect that stat(3) may be successful, only the conversion to > > integer(kind=4) has an overflow in some component. Is it then > > helpful to return ERANGE? Or just return -1 for those components > > and document this new behavior? > > Good point. I'd say set only the overflowing component to -1 and > document the behavior. It's possible the user is interested in some > component that doesn't overflow, and returning ERANGE would break > backwards compatibility? > > As an aside, I note the documentation for [F,L,]STAT says the VALUES > array and STATUS should be INTEGER(4), which isn't correct is it? It > should be default kind INTEGER? We probably want to make these GNU extensions generic. I did this for kill() and there are additional patches in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30372 for umask() and unlink(). > > > And don't forget that returning ERANGE needs adjustment of > > testcases, where the only portable solution I have is the > > specification of -fdefault-integer-8 ... > > That might be a topic for a follow-up patch, but it would be useful to > be able to use the kind=8 version without having to redefine the > default integer size (which might need some additional headscratching > to deal with VALUES of INTEGER(kind=8) and STATUS of default kind..). > And then the documentation should recommend using that version in > order to avoid overflows. Personally, I would like to see -fdefault-integer-8 deprecated, but that ship sailed long ago. Most intrinsic subprograms specified in the Fortran are generic. Perhaps, gfortran's extension should follow suit. -- Steve
