From patchwork Sun Sep 1 16:53:47 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thomas Koenig X-Patchwork-Id: 271630 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "www.sourceware.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by ozlabs.org (Postfix) with ESMTPS id D77A72C0087 for ; Mon, 2 Sep 2013 02:54:12 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type; q=dns; s=default; b=ijUOVA378IXsh50tW OGoSOWiEnSzae00ESU404ljaYBMsAGN0ovakifV5y/llSHarpnFQ5M9cu2U2h/Qc K4yMCOUiKJyJcgjjqrNErP704bTg1lPf8E1E4XWaJmGBI1Tlln/ch+cdHLDtaxd0 kHotqcahm9KjT068MECUUdWdL4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type; s=default; bh=Tdh4Wybu6q6pegdNteJ50zV 3Nkc=; b=muaHylYcVk2f9VWNSj7Q/ftPUb37fROLEMtctm+A+++7OItUr8YKyp2 Ewkoh9ps+Jd/whMCCm6iMdgrEqJq6M8HmOkLz8QfmKTZpAy3/dsAz6OkTzjAD7JE 9hqGZD+0SB1k7KCLQpJlZW4P5rFu5N9b7e9NLtaTbjQMWo8nvbrI= Received: (qmail 28489 invoked by alias); 1 Sep 2013 16:54:06 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 28467 invoked by uid 89); 1 Sep 2013 16:54:06 -0000 Received: from cc-smtpout2.netcologne.de (HELO cc-smtpout2.netcologne.de) (89.1.8.212) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Sun, 01 Sep 2013 16:54:06 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.2 required=5.0 tests=AWL, BAYES_00, KHOP_THREADED, RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: cc-smtpout2.netcologne.de Received: from cc-smtpin2.netcologne.de (cc-smtpin2.netcologne.de [89.1.8.202]) by cc-smtpout2.netcologne.de (Postfix) with ESMTP id 00A1212059; Sun, 1 Sep 2013 18:53:51 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by cc-smtpin2.netcologne.de (Postfix) with ESMTP id D2C5011D96; Sun, 1 Sep 2013 18:53:50 +0200 (CEST) Received: from [87.79.198.241] (helo=cc-smtpin2.netcologne.de) by localhost with ESMTP (eXpurgate 4.0.0) (envelope-from ) id 5223711e-053f-7f0000012729-7f000001936e-1 for ; Sun, 01 Sep 2013 18:53:50 +0200 Received: from [192.168.0.104] (xdsl-87-79-198-241.netcologne.de [87.79.198.241]) by cc-smtpin2.netcologne.de (Postfix) with ESMTPSA; Sun, 1 Sep 2013 18:53:48 +0200 (CEST) Message-ID: <5223711B.1090000@netcologne.de> Date: Sun, 01 Sep 2013 18:53:47 +0200 From: Thomas Koenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Janne Blomqvist CC: "fortran@gcc.gnu.org" , gcc-patches Subject: Re: [patch, fortran, docs] Unformatted sequential and special files References: <5220D3E4.2010905@netcologne.de> In-Reply-To: Hi Janne, I have tried to answer your points in the attached patch. > The unformatted sequential format part looks Ok, but the special files > section is lacking. E.g. what about > > - The REWIND statement? Not supported. > - The ENDFILE statement? Not supported. > - ACCESS='stream' and the POS= specifier? Only for inpquire. > - ACCESS='direct'? (I suspect this should work for > pipes/FIFO's/terminals in case REC= numbers are sequential, but is > that a guarantee we want to make?) I have not listed this as supported in the patch. > - Special files which are special in other ways. E.g. block special > files tend to allow seeking, but IO must be block aligned. Also listed as not supported; I suspect buffering could cause grief there. I have updated an attached patch. OK? Thomas 2013-08-30 Thomas Koenig PR fortran/30162 * gfortran.texi: Document unformatted sequential file format and I/O with special files. ig25@linux-fd1f:~/Krempel/Unformatt Index: gfortran.texi =================================================================== --- gfortran.texi (Revision 201996) +++ gfortran.texi (Arbeitskopie) @@ -1121,6 +1121,8 @@ * Internal representation of LOGICAL variables:: * Thread-safety of the runtime library:: * Data consistency and durability:: +* Unformatted sequential file format:: +* I/O with special files:: @end menu @@ -1291,7 +1293,85 @@ releasing @code{fcntl} file locks, if the server supports them, will also force cache validation and flushing dirty data and metadata. +@node Unformatted sequential file format +@section Unformatted sequential file format +@cindex unformatted sequential files +@cindex record marker +@cindex subrecord +Unformatted sequential files are stored using record markers. Each +full record consists of a leading record marker, the data written +by the user program, and a trailing record marker. The record markers +are four-byte integers by default, and eight-byte integers if the +@option{-fmax-subrecord-length=8} option is in effect. Each record +marker contains the number of bytes of data in the record. + +The maximum number of bytes of user data in a record is 2147483639 for +a four-byte record marker. If this is exceeded, a record is split into +subrecords. Each subrecord also has a leading and a trailing record +marker. If the leading record marker contains a negative number, the +number of user data bytes in the subrecord equals the absolute value +of this number, and another subrecord follows the current one. If the +trailing record marker contains a negative number, then the number of +bytes of user data equals the absolute value of that number, and there +is a preceding subrecord. + +The format for unformatted sequential data can be duplicated using +unformatted stream, as shown in this example program: + +@smallexample +program main + implicit none + integer :: i + real, dimension(10) :: a, b + call random_number(a) + open (10,file='test.dat',form='unformatted',access='stream') + inquire (iolength=i) a + write (10) i, a, i + close (10) + open (10,file='test.dat',form='unformatted') + read (10) b + if (all (a == b)) print *,'success!' +end program main +@end smallexample + +@node I/O with special files +@section I/O with special files +@cindex special files +@cindex pipes +@cindex FIFO +@cindex terminal devices +@cindex block devices +@cindex sockets +@cindex BACKSPACE +@cindex REWIND +@cindex ENDFILE + +Special character-oriented files such as pipes, FIFOs or terminal +devices are supported only for the following types of file access: + +@itemize + +@item Formatted sequential + +@item Formatted stream + +@item Unformatted stream + +@end itemize + +For special files, the @code{POS=} specifier for stream I/O can only +be used in @code{INQUIRE} statements. + +Unformatted sequential file access is @emph{not} supported for special +files. If necessary, it can be simulated using unformatted stream, +see @ref{Unformatted sequential file format}. + +I/O to and from block devices are also not supported. + +@code{BACKSPACE}, @code{REWIND} and @code{ENDFILE} are not supported +for special files. + @c --------------------------------------------------------------------- @c Extensions @c ---------------------------------------------------------------------