[J3] ballot #38

Robert Corbett rpcorbett at att.net
Mon Jan 24 11:25:00 UTC 2022


Here is my vote on ballot #38.
Robert Corbett
Yes  No   Number    Title

---  -N-  F18/025  Is component initialization an attribute?
-Y-  ---  F18/033  E/EN/ES/D output exponent when w=0
-C-  ---  F18/034  Purity of IEEE_GET_FLAG and IEEE_GET_HALTING_MODE

----------------------------------------------------------------
F18/025 N

I previously argued that the proposed answer could break more
existing code than other possible emendations and that
treating default initializations as attributes is unintuitive.
In reviewing the proposed answer for interpretation F18/025, I
realized that the proposed answer creates a restriction that
cannot, in the general case, be checked at compile time.  Other
possible fixes for the problem could be checked at compile time.

An obvious way to evade the compile-time checks is to define an
external procedure that has a dummy argument which has the
version of the sequence or BIND type that does not have default
initialization.  Checking whether procedures match their
interfaces in other files cannot be checked at compile time,
and so, a call or function reference can create a case where
the pointer value becomes accessible.  The mismatch between
the the interface and the procedure could be detected at link
time or run time, but implementations that do such checks are
rare.

The problem that needs to be solved is that default
initialization of components creates a means to assign a data
object pointer a value that could allow pure code to define or
redefine a variable that should not be touched.  The
constraints placed on pure code to avoid this problem for
variables do not allow the such assignments.  Placing similar
restrictions on components with default initializations of
object pointers solves the problem in a way that can be
detected at compile time.  Sequence and BIND types could be
banned from appearing in array and structure constructors, in
object declarations, and in the MOLD= specifiers of ALLOCATE
statements.

Many other ways of solving the problem are possible, but the
one proposed above closely corresponds to the existing
restrictions on pointers that are not components.

----------------------------------------------------------------
F18/034 C

The additional restrictions proposed in F18/034 are not
necessary in the Fortran 2018 standard.  No context in which
IEEE_GET_FLAG and IEEE_GET_HALT_MODE may appear causes a
problem for PURE procedures.  The proponent of this answer for
the interpretation argued that it would be easy to extend the
language to create cases where the restrictions are needed.  I
agree that it is possible to extend the language in a way that
the restrictions needed.  I do not think it will be easy.

The restrictions are unnecessary, but not onerous, so I do not
object to the proposed answer to F19/034.
----------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20220124/fa2f8a76/attachment.htm>


More information about the J3 mailing list