From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Sat Aug 18 11:33:16 2012 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 48B5935696A; Sat, 18 Aug 2012 11:33:16 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from mk-filter-3-a-1.mail.uk.tiscali.com (mk-filter-3-a-1.mail.tiscali.co.uk [212.74.100.54]) by www.open-std.org (Postfix) with ESMTP id 860F33568FD for ; Sat, 18 Aug 2012 11:33:14 +0200 (CEST) X-Trace: 794138079/mk-filter-3.mail.uk.tiscali.com/B2C/$THROTTLED_STATIC/TalkTalk_Customer/92.21.185.182/None/John.Reid@stfc.ac.uk X-SBRS: None X-RemoteIP: 92.21.185.182 X-IP-MAIL-FROM: John.Reid@stfc.ac.uk X-SMTP-AUTH: X-Originating-Country: GB/UNITED KINGDOM X-MUA: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120715 Firefox/14.0.1 SeaMonkey/2.11 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBABxgL1BcFbm2/2dsb2JhbAANOL1mAQEBBAEBATUbGwoRCxgJFg8JAwIBAgEVMAYNBgICiBSmLIpsiQSLC4cSA5VPgRSENY0qgWA X-IronPort-AV: E=Sophos;i="4.77,790,1336345200"; d="scan'208";a="794138079" Received: from host-92-21-185-182.as13285.net (HELO [127.0.0.1]) ([92.21.185.182]) by smtp.tiscali.co.uk with ESMTP; 18 Aug 2012 10:33:13 +0100 Message-ID: <502F6187.1080804@stfc.ac.uk> Date: Sat, 18 Aug 2012 10:33:59 +0100 From: John Reid User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120715 Firefox/14.0.1 SeaMonkey/2.11 MIME-Version: 1.0 To: WG5 Subject: Re: (j3.2006) (SC22WG5.4723) WG5 letter ballot on N1929 References: <20120817095648.607253568FA@www.open-std.org> <502E73D7.5020707@net-b.de> In-Reply-To: <502E73D7.5020707@net-b.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-sc22wg5@open-std.org Precedence: bulk Tobias, I will treat this as a "yes with comments" vote. If you want to make any changes or additions (perhaps after email correspondence) please send me a complete new set of comments. Thanks, John. Burnus wrote: > On 08/17/2012 11:56 AM, John Reid wrote: >> N1929, draft Fortran Annex to TR 24772, >> Guidance to Avoiding Vulnerabilities in Programming Languages through >> Language Selection and Use. > > A few smaller remarks ... feel free to completely ignore them. > > Fortran.14 Null Pointer Dereferences [XYH] > > I think the guidance should also recommend/mention nullifying pointers; > it doesn't help with the issue itself, but the mentioned associated only > works if the status is not undefined and as variables are never > automatically initialized to null (contrary to other languages, where > that happens at least for static/SAVE variables) and as one easily > forgets to nullify them, I think one could mention it here. > > > Fortran.15 Dangling References to the Heap > > "Do not pointer-assign a pointer to a target when the pointer has a > longer lifetime than the target" > > While it is implicitly both in that sentence and more explicitly in the > standard: The pointer should also not outlive the lifetime of the target > attribute of the target. I mean the following case "subroutine (a); > target :: a; ptr => a" if the actual argument to "a" has neither the > target nor the pointer attribute. > > > Fortran.22 Identifier Name Reuse > > (I think Fortran lacks a way to disallow/restrict host association. > Currently, one can get odd results if one forgets to declare a variable > (e.g. "integer :: i") and accidentally uses the host-associated > variable; and "implicit none" doesn't help. - I just saw that it is > covered in Fortran.58) > > > Fortran.55 Undefined Behaviour [EWF] > > "Specify the external attribute for all external procedures invoked" > > While that avoids issues with intrinsic procedures, I think one should > recommend an explicit interface, especially one provided via > use-association or internal procedures. (That's already mentioned in > [OTR], but here it sounds like an explicit "external" recommendation. I > think one could also mention something like that in [LRM].) > > > Fortran.58 > "Future standarization efforts should consider:" > > I wonder how the following is supposed to work in general - and not only > in very specific cases: "Requiring that processors have the ability to > detect and report the occurrence within a submitted program unit of > invalid pointer references during program execution." > > Some of the other ideas sound fine - and I am especially looking forward > to a means to restrict the host association, e.g. noimport / import :: > list / import, where a compiler could provide -fnoimport in a similar > way to -fimplicit-none to find unintended host associations. > > Tobias > _______________________________________________ > J3 mailing list > J3@mailman.j3-fortran.org > http://mailman.j3-fortran.org/mailman/listinfo/j3 >