This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: iostat
On Wed, Aug 23, 2006 at 10:06:38AM +0200, Daniel Franke wrote:
>
> 2006/8/23, Steve Kargl <sgk@troutmask.apl.washington.edu>:
> >Unfortunately, gfortran runs on more than just a few operating
> >systems. While open(2) on many Unix-like system probably returns
> >ENOENT, EACCESS, etc., we would need to determine the corresponding
> >errors on all supported OS's.
>
> 2006/8/23, Erik Edelmann <erik.edelmann@iki.fi>:
> >What about assigning the value of errno to iostat,
>
> Given Tobias' example for IOMSG, I assume that gfortran has all the
> necessary information at its disposal, but just passes 'IOSTAT=1' to
> the user.
IOMSG and IOSTAT are different features (otherwise, IOMSG would
never have been added to F2003). IOMSG is essentially asking the
compiler/OS to give you information concerning the state of IO
in human readable words. gfortran doesn't need to assign unique
IOMSG strings because the compiler/OS automatically gives it to us.
IOSTAT is a value. That value needs IMNSHO to be unique across
all OS's.
> Implementing Erik's suggestion would allow those who care to
> determine the appropriate message on their own.
I think that that is an ugly solution. Telling a Fortran programmer
(who may have no C language experience) to compile and run a C
code or look in errno.h to translate a number into a more meaningful
message seems worse than just signalling failure.
> As a developer who is going to be bugged by users along lines as "It
> says 'XXX failed' - what's wrong?" I would really appreciate _any_
> starting point, including an arbitrary and system dependent error
> number.
This is the problem! Who is going to document all of the error
numbers in gfortran.texi? Surely, you can appreciate the sorry
state of gfortran documentation. I suppose we can have a Table.
UNIX WINDOWS DARWIN yada ....
File not found 1 42 2 1 ....
Access Permission 2 1 1 5 ....
Hidden file 2 ? 6 ....
Don't get me wrong. I'm not opposed to implementing better
error messages. I think some people fail to see the potential
size of the problem. Perhaps, someone should add a bug report
requesting an enhancement that IOSTAT return unique error codes
for various modes of failure.
--
Steve