J3/07-128
To: J3
Date: 24 January 2007
From: Bill Long
Subject: UTI 76: definition status and bits
References: J3/07-007

Discussion

UTI 76 (page 500) proposes to change the text currently at
[499:41-42], which reads

  "(16) When a dummy argument of type bits that is associated with an
  effective argument of a different type becomes defined, the
  effective argument becomes defined."

to (text at the end of the J3 internal note, top of page 500)

  "(16) When a dummy argument of type bits that is associated with an
  effective argument of a different type becomes defined, whether the
  effective argument becomes defined is processor dependent."

The argument in the internal note is based on enhancing
portability. It is difficult to see how making an action "processor
dependent" improves portability.  It certainly reduces usefulness.

The internal note mentions several types of mismatches that could
possibly lead to nonportable results, including real, integer, and
logical actual arguments associated with a bits dummy argument. The
effect of all these cases can already be accomplished, though
clumsily, with the use of the TRANSFER intrinsic. Additionaly, some
processors already allow argument type mismatches through non-portable
compiler directives. The goal of the new feature is to provide a
standardized and portable mechanism for accomplishing this effect.

Furthermore, the C lanugage allows such mismatches to a much greater
degree that Fortran 2008 without causing catastrophe.  For example,
consider the void * 'buffer' dummy argument in the wide array of
routines in communications libraries. The feature of allowing
BITS dummy arguments to correspond to non-BITS actuals allows generic
interfaces to be written for library routines of this nature with
fewer specific interface bodies.

The effect of the proposed change is to make a subroutine

    SUBROUTINE MOVE8 (TO, FROM, NWORDS)
      INTEGER,INTENT(IN) :: NWORDS
      BITS(64),INTENT(IN) :: FROM(NWORDS)
      BITS(64),INTENT(OUT) :: TO(NWORDS)
      TO = FROM
    END SUBROUTINE MOVE8

useless for the obvious intended purpose. With the current wording
such a routine has a clear, useful, and portable meaning.  With the
proposed change, calls to the routine with a nonbits actual argument
associated with TO become non-portable.  This is a step in the
wrong direction.

MOVE8 can be used with 64-bit REAL IEEE actual arguments to avoid the
non-portable IEEE copy rules, resulting in code that is actually more
portable.

The internal note also states "Bit-twiddling the guts of a Fortran
data type is {/it inherently} processor-dependent. We should have the
guts to say that."  This statement is not related to argument
association, so it is not clear how it is relevant to the rest of the
discussion.  However, users who want to bit-tiddle the guts of an
object are going to do it anyway. Without the BITS capabilities, the
resulting codes are more error prone, harder to maintain, and less
portable. And there are quite reasonable cases for such bit-twiddling.
For example, consider a generic subroutine that swaps the endian of
words of a particular size.  This operation depends only on the size
of the data object, independent of whether it represents a real,
integer, logical, or bits value.


In summary, the current wording at [499:41-42] enhances code
portability and, thus, supports that primary goal of the standard.
The proposed change reduces both portability and usefulness, and is
therefore undesirable.


Edits to J3/07-007

(none)