iostat

[Steve Kargl]

On Wed, Aug 23, 2006 at 11:35:20AM -0700, Richard E Maine wrote:
> On Aug 23, 2006, at 9:34 AM, Steve Kargl wrote:
> 
> >IOSTAT is a value.  That value needs IMNSHO to be unique across
> >all OS's.
> 
> I guess I don't see why the commonality of that value across  
> operating systems is particularly important. I can see why it might  
> be nice, but it isn't very high on my list of important things - not  
> anywhere near as high as the importance of having the value encode  
> something useful. The value sure is not portable across different  
> compilers, even on the same OS.

You are the (former?) editor of J3, right?  The problem is
documentation.  It's easier to have gfortran.info state that
iostat is 1 on failure to open a file than to tell a user the
value corresponds to a value listed in errno.h.  errno.h may
not even exist on the user's system!  So, they go ask Joe Linux
what errno value 35 means even though linux errno 35 does not
correspond to the user's errno 35.

Well, I just checked /usr/include/errno.h on FreeBSD and RedHat.
FreeBSD's version includes the actual errno values.  RedHat's
doesn't include the values.  It includes a contorted mess of
C preprocessor directives, which includes /usr/include/bits/errno.h.
But wait, bits/errno.h includes 4 values that are probably never used 
(due to the C preprocessor directives), and it includes linux/errno.h.
Oh joy, linux/errno.h includes asm/errno.h.  OK, asm/errno.h has
some values.

Errno 35 on linux is EDEADLK = 'Resource deadlock would occur',
which corresponds to FreeBSD's errno 11.  Errno 35 on FreeBSD is
EAGAIN = 'Resource temporarily unavailable', which corresponds
to RedHat's errno 10.

> >>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.
> 
> You are kidding, right? If you are serious, then I guess we just have  
> hugely different value judgments here because I find it hard to  
> disagree more. Although both options are far from ideal, I'd take the  
> hard-to-interpret number over "failed - you guess why" any day.  By a  
> lot. At least with the number, the poor user can go ask someone else  
> for help interpreting it. Indeed, I see users asking exactly that  
> quite regularly. With "open failed - you guess why", the user is just  
> plain going to be out of luck. As the poor user, try asking for help  
> with that one somewhere like comp.lang.fortran... and lots of luck,  
> as you would need it.

No, I'm not kidding.  It simply comes down to documentation.  gfortran.info
is in a sorry state at the moment.  Evidently, the documentation will
catch up to gfortran.  Listing all of the errno values from all of the
operating systems that gfortran supports would be a mess.  Telling a
user to look in errno.h (to me) isn't a viable solution.

> I have trouble picturing why you would think that it is ok to  
> dispense with giving any information at all, yet it is important to  
> have the same non-information on all operating systems. You and I  
> must have some pretty basic differences in outlook somewhere.

I'm not opposed to giving information to a user.  I simply think
that returning a vague iostat=errno value is only marginally better
than the all inclusive 1 that is returned at the moment.  In fact,
I've already stated that a documented non-standard iostat_to_msg()
intrinsic subroutine could be a possible solution.

-- 
Steve