This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch, fortran, docs] Unformatted sequential and special files
- From: Janne Blomqvist <blomqvist dot janne at gmail dot com>
- To: Thomas Koenig <tkoenig at netcologne dot de>
- Cc: Tobias Burnus <burnus at net-b dot de>, "fortran at gcc dot gnu dot org" <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 4 Sep 2013 13:40:19 +0300
- Subject: Re: [patch, fortran, docs] Unformatted sequential and special files
- Authentication-results: sourceware.org; auth=none
- References: <5220D3E4 dot 2010905 at netcologne dot de> <CAO9iq9Ebu+UMtpPzRCCipv7C0xH8H95sbaZX3pFydb22ao2u2g at mail dot gmail dot com> <5223711B dot 1090000 at netcologne dot de> <5224EAED dot 2090000 at net-b dot de> <5225D048 dot 8030902 at netcologne dot de>
On Tue, Sep 3, 2013 at 3:04 PM, Thomas Koenig <tkoenig@netcologne.de> wrote:
> Hello world,
>
> here is a rewrite, which I hope make things more clear.
> Unformatted sequential files are now made up of subrecords, where
> a logical record may only have one.
Looks ok.
> Regarding block devices: I don't know anybody who ever used them
> from gfortran, so I tried to be as vague as possible.
>
> Any more suggestions? OK for trunk otherwise?
I'm still not comfortable with the wording. As I've argued before,
special files are special in different ways, and can behave
differently on different systems, so it's difficult to say anything
definitive about their behavior in general. Maybe being more explicit
about what is supported for a limited subset would help. E.g. starting
the section with something like
"For terminal devices, pipes, FIFO's and sockets the following file
modes are supported:
- ...
For other special files and other file modes, the result is undefined."
("undefined" rather than "not supported", as we're not going out of
our way to prevent it if somebody wants to do it either)
- Wrt the POS= specifier with INQUIRE, even it it "works" (as in, does
not generate an error), there is no sensible concept of file position
for a stream file anyway, so perhaps we shouldn't explicitly say it's
supported either.
- Wrt. block devices, perhaps remove that section and cover it just
with the "...implementation defined" sentence above.
--
Janne Blomqvist