On Nov 24, 2004, at 7:56 AM, Aleksandar Donev wrote:
> That [the set of I/O errors being processor-dependent] is unfortunate,
Agree. I even used the same word "unfortunate" in part of my wordier
comment on it.
> Are you saying that most compilers will either
> check for an error with or without IOSTAT (and abort in the former or
> continue in the later case), or not check for it at all?
I don't recall saying anything at all about "most compilers" and I
don't think I'll commit myself to any such statement. I mentioned what
behavior I would hope for; I meant that literally with no other
interpretation implied. I haven't made a survey of it.
I make sure that my own outputs won't overflow buffers. Yes, I'm aware
that this is sometimes nontrivial. It is particularly nontrivial for
things like list-directed and namelist output, where the compiler has
many options and the user doesn't have any way of knowing what
particular options the compiler uses. Fortunately for me, I've never
used namelist internal output, and my uses of list-directed internal
output are pretty simple.
Note that list-directed and namelist internal I/O used to be
disallowed. This is *NOT* a coincidence. My understanding is that was
exactly part of the reason, perhaps even the whole reason. But
list-directed internal I/O is so widely useful that it later got added
anyway in spite of this problem. After all, in at least the simplest
cases, it is easy for the user to provide buffers that are more than
adequate for any eventuality... and it isn't an issue at all for input.
--
Richard Maine | Good judgment comes from experience;
[log in to unmask] | experience comes from bad judgment.
| -- Mark Twain
