On Oct 31 2014, Janne Blomqvist wrote:
My main aim here really is to just get the basics right before
worrying about corner cases. For instance, I recall we have failed in
a simple sequential reading of a access="sequential", form="formatted"
unit connected to a pipe or such, because libgfortran incorrectly
issued a lseek() at some point, which returned an error (since the fd
wasn't seekable), and that error was then duly propagated upwards. But
since the testsuite didn't test against this, it took an
embarrassingly long time before that bug was found and fixed.
Yes. I agree. But see my next point.
So the first question is to decide the priority of I/O variations,
including types of file and permitted operations for each connection
mode. The key characteristics (in OPEN) are ACCESS, FORM and ACTION.
In particular, there is disagreement on WG5 exactly what constitutes a
'file' - I have been told that magnetic tape files and sockets are not
files by someone who ought to have known better. For example, does
gfortran intend to support the piping of unformatted files? Not all
compilers do.
My argument in this, which I have stated many times on the mailing
list and in bugzilla over the years, is that there are many kinds of
special files which are special in different ways. E.g. wrt. seeking,
some special files allow seeking just fine, others report an error,
and others always report an offset of 0. Instead of trying to
enumerate in which ways special files are special on all supported
targets, which is a sisyphean task, libgfortran should just do what
it's being told to, no more, and if any error occurs, propagate it
upwards to the calling program. The "no more" is the problematic
part, e.g. a spurious lseek(fd, 0, SEEK_CUR) would have have no effect
on a regular file, but cause an error on a non-seekable file. Hence
the need for a testsuite for non-regular files.
Again, I agree, but that wasn't quite my point. I fully agree that
providing such a list in the release notes is insanity. What I feel
needs doing is a generic priority list of which functionality should
take priority over which, for the guidance of gfortran developers and
maintainers. Naturally, it would be subject to change. The point is
that the choice of open() options, data format and OS transfer calls
constrains what will work, and so you have to choose before you know
what the code will do. The most ancient and worst insanity is not
knowing the initial direction of transfer, but (as you say)
repositioning and truncation vs replacement are almost as ancient
and bad :-(
While I would much prefer such decisions being made at OPEN time,
my attempt to get this supported (not required!) in the standard
failed. But there ARE some simple decisions that could be taken;
for example (and these are merely PROPOSALS):
If it is not a 'regular' file, ACCESS='DIRECT' should be forbidden
If it is a FIFO, at least BACKSPACE and POS= should be forbidden
Important decisions of priority would include whether pipability should
take precedence over positionability for (a) stream and (b) unformatted
sequential files. The Unix lunacy of compounding stream I/O with
direct-access I/O (i.e. ACCESS='STREAM') has always been a disaster for
both RAS and portability. And I really don't know what most compilers'
attitudes are to that one, despite having asked several developers!
For what I'm thinking of, I'm sure a pretty basic POSIX sh + maybe a
few utilities such as mkfifo would do just fine. My reason for wanting
to limit it, is that I, and AFAIK most gfortran developers, develop
and test on x86_64-unknown-linux-gnu, and with the very limited time
that I can afford to gfortran these days I don't want to spend that
time trying to debug-over-email why a script fails on some weird
target I don't have access to. If you want to make it work on Ultrix
or something like that, be my guest, patches welcome. (For a similar
reason, I think it wouldn't make sense to run these tests in a cross
environment, more complexity for little gain (unless it's really
simple?).)
Yes, but this is EXACTLY the sort of thing that fails on those systems,
and such tests would be really, really useful for people working on such
systems. What I would suggest is that the scripts be supported for a
generic POSIX system, but not be enabled by default or in a way that
J. Random User is likely to trip over.
Regards,
Nick Maclaren.
