DejaGNU gurus ahoi! (Re: Testing use of STDIN redirected etc.)

[N.M. Maclaren]

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.