Am 17.06.25 um 21:27 schrieb Harald Anlauf:
Am 17.06.25 um 19:44 schrieb Steve Kargl:
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.
OK, here is the conservative version along what Janne suggested,
with a documentation update: as a matter of fact, we currently
do support only default integer (which is kind=4, unless
-fdefault-integer-8 is specified) in the frontend,
We return -1 for elements where there would be overflow, but nothing
like ERANGE or so in STATUS. If someone strongly feels that an error
should be returned, and a mechanism to make it possible to portably
detect this, this should become a separate PR.
With this version, no tweaking of existing tests is needed.
I intend to commit this within the next 24-48 hours as part 1
if it is ok.
Thanks,
Harald
Pushed as r16-1560-gce6abe54ff1548.
