[J3] Fortran annex to 24772 and the work with WG23 on "Guidance to Avoiding Vulnerabilities in Programming Languages through Language Selection and Use"

Bill Long longb at cray.com
Thu Jan 23 14:10:19 EST 2020



> On Jan 23, 2020, at 12:04 PM, Vipul Parekh via J3 <j3 at mailman.j3-fortran.org> wrote:
> 
> On Thu, Jan 23, 2020 at 11:49 AM Dan Nagle via J3
> <j3 at mailman.j3-fortran.org> wrote:
>> ..
>> Under the heading of "old business",
>> JoR will look at the Fortran annex to 24772; this is the work
>> for the joint meeting with WG23.
> 
> Dan and anyone working toward the joint meeting with WG23,
> 
> Would you know the process to get better clarity on the work with WG23
> and how J3/WG5 intends to follow up on the stated Implications?
> 
> By implications, I mean items such as the last one from Fortran.58
> Implications for Standardization in WG5 document N1965 which states,
> "Identifying, deprecating, and replacing features whose use is
> problematic where there is a safer and clearer alternative in the
> modern revisions of the language or in current practice in other
> languages."
> 
> With this item,
> 
> -  What will "deprecating" mean in the context of Fortran standard if
> such an implication remains in the output of this joint work with
> WG23?
> 
> -  Fortran standard has "obsolescent" and "deleted" but not "deprecated’.

“obsolescent” is a polite way of saying  “deprecated”.  See 4.4.3 for the meaning of “obsolescent”, which is pretty close to what most people mean by deprecated. Particularly the bit about being candidates for the “deleted” list in the future.

> 
> -  And there are some aspects in the Fortran standard that are clearly
> "problematic" such as
>   * implicit typing and how this nasty, nasty, nasty "legacy"
> persists through new scopes introduced starting Fortran 90 such as
> MODULEs and INTERFACE blocks,

This is why we have IMPLICIT NONE. We do not want to make the Python mistake of creating an incompatible language.


>   * and the indescribably reprehensible "implied SAVE" (c.f. sections
> 53.1 and 53.2 in WG5 document N1965)

The implied SAVE stuff was mainly just standardization of existing practice. 

> 
> - What will "replacing" mean in the context of Fortran standard?
> 

We usually provide a new feature first, then make the redundant old feature obsolescent. 


> With certain "is-it-a-feature-or-is-it-a-bug" in the Fortran standard,
> there appears a strong resistance to deletion on the committee when
> the very few like me trying to retain a role for Fortran in industry
> would very much prefer deletion.  

The main reason vendors (and the committee) resist deleting features is that industry demands they remain. So that old codes continue to work.  (Many of  the ones marked as deleted in the standard are still supported because of customer - almost always industry - demand that the the old features continue to work.)   Vendors tend to listen to the ones paying the bills and the ones supplying benchmarks for procurement competitions. 


> This preference is only due to
> continued experiences with negativity and relentless ridicule fostered
> by FORTRAN and its "legacy" with implicit typing and implied SAVE
> which leads to powers-that-be signing off on codebase after codebases
> to move away from Fortran to other programming languages.

None of this harms in any way a programmer writing a new code who does not use the old features. 

> 
> Without deletion, I don't quite see how one ends up "replacing
> features", I only see "adding features" to the language but then
> status quo with continued vulnerabilities in user codes facilitated by
> continued processor support.  That is,.until senior leadership in
> enterprise(s) wield the axe and shift the whole damn code away from
> Fortran.

This seems like a corporate management problem.   There are cures for that, but mainly outside the scope of the committee. 

Cheers,
Bill

> 
> Can the joint work with WG23 lead to further discussion of these
> concerns when it comes to the future direction of the Fortran
> standard?
> 
> Thanks,
> Vipul Parekh

Bill Long                                                                       longb at cray.com
Principal Engineer, Fortran Technical Support &   voice:  651-605-9024
Bioinformatics Software Development                      fax:  651-605-9143
Cray, a Hewlett Packard Enterprise company/ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425





More information about the J3 mailing list