The old POSIX Fortran spec defined the PXFCONST subroutine and IPXFCONST function to provide portable access to constants such as ERANGE. Perhaps adding them to the gfortran library would be useful?
Walter Sent from my iPhone > On Jun 17, 2025, at 4:05 AM, Janne Blomqvist <blomqvist.ja...@gmail.com> > 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. > >> - 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? > >> 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. > > -- > Janne Blomqvist >
