From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32473 invoked by alias); 7 Mar 2015 09:36:17 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 32456 invoked by uid 89); 7 Mar 2015 09:36:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_FROM_URIBL_PCCC,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=no version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-wi0-f171.google.com Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com) (209.85.212.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Sat, 07 Mar 2015 09:36:15 +0000 Received: by widem10 with SMTP id em10so8759129wid.1; Sat, 07 Mar 2015 01:36:12 -0800 (PST) X-Received: by 10.180.108.13 with SMTP id hg13mr40672919wib.7.1425720972641; Sat, 07 Mar 2015 01:36:12 -0800 (PST) Received: from touille.bouyguesbox.fr (89-93-42-249.hfc.dyn.abo.bbox.fr. [89.93.42.249]) by mx.google.com with ESMTPSA id hw7sm14727713wjb.24.2015.03.07.01.36.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Mar 2015 01:36:11 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: [PATCH, libgfortran] PR 65200 Handle EPERM as EACCES From: FX In-Reply-To: Date: Sat, 07 Mar 2015 09:36:00 -0000 Cc: Fortran List , GCC Patches Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Janne Blomqvist X-SW-Source: 2015-03/txt/msg00412.txt.bz2 Hi Janne, > the attached patch makes GFortran handle errno=3DEPERM in the same way > as EACCES (this affects only when no ACTION=3D specifier is used in the > OPEN statement and opening the file in read-write mode fails). Makes sense. > The patch also contains a doc snippet to explain how GFortran behaves > when no ACTION=3D is given when opening a file. Great. > This brings me to a > standards interpretation question: When no ACTION=3D is given, F2008 > 9.5.6.4 (ACCESS=3D specifier in OPEN statement) says: "If this specifier > is omitted, the default value is processor dependent." So does this > mean that the current GFortran behavior is allowed, or must the > behavior be exactly as with one of the possible ACTION=3D specifiers > (READ, WRITE, READWRITE)? I think we are standard-confirming: we open the file with one of the specif= iers, determined in a processor-dependent fashion. Except our process-depen= dent value is not a constant, it depends on the file chosen (and its permis= sions). I believe that=E2=80=99s still within =E2=80=9Cprocessor dependent= =E2=80=9D. And it certainly makes more sense that the other possibilities. Thus, OK to commit. FX