(j3.2006) (SC22WG5.4577) Comments on N1885

Van Snyder Van.Snyder
Thu Oct 27 19:26:58 EDT 2011


On Thu, 2011-10-27 at 14:22 -0700, Bill Long wrote:
> Thanks, Van, for carefully reading through the draft. Responses for some 
> of your observations:
> 
> On 10/26/11 1:34 PM, Van Snyder wrote:
> >
> > I have a few (possibly misguided) comments on N1885.

> > 5.4.2p1: It seems to be OK for a processor to decide that
> >    pure real function xyz ( x )
> >      integer, intent(in) :: x
> >      xyz = x + 1.0
> >    end function xyz
> > is an asynchronous communication initiation or completion procedure.
> >
> 
> So, you are saying that the description is too vague?

It says "whether a procedure is... is processor dependent"  That seems
to allow the processor to decide either way.  I thought it should have
said nothing, or that the program determines whether a procedure is an
asynchronous communication initiation or completion procedure, but
Malcolm argued against this proposition.

I don't know how to say that the processor might have a list of
procedures that it knows to be asynchronous communication initiation or
completion procedures, and that it somehow knows that a Fortran (or C)
procedure that calls ... that calls (a dozen levels down) one of the
procedures on the list is also an asynchronous communication initiation
or completion procedure, and that no others are.  If the processor is
free to determine that the procedure in the example is an asynchronous
communication initiation or completion procedure, all procedures might
as well be asynchronous communication initiation or completion
procedures... so why say anything at all?

> > 6.4.1p1: I don't understand how the expression can work.

Bill didn't comment on this one.  I don't understand how the result can
include the final element, size(array,rank(array),kind), if array is
assumed size.

> > 6.4.3p1: After "result" insert "of UBOUND(ARRAY,RANK(ARRAY),[KIND])".

Bill didn't comment on this one.  I assume the result only has the
described value in the case commented here.

> > 8.3.5.3p7: The example would be more informative if the bounds were
> > different.  Inquiring minds might realize that Fortran and C bounds
> > have opposite ordering, and wonder which order they ought to appear in
> > the lower and upper arrays.
> >
> 
> The upper bounds are already different (100 and 1000). Would 100 and 500 
> be better?

Yeah, 100 and 500 would be better.  I obviously looked at it quickly and
saw 100 twice.

> > 8.3.5.5 generally: It's not obvious how to establish an assumed-length
> > character scalar.
> >
> 
> Do you mean one for which the length is deferred?

I was thinking of the need to describe an actual argument that will
become associated with a dummy argument that is an assumed-length
character scalar.  Something like "char c[42];" being passed to
"character(len=*,kind=c_char) :: c"

8.3.5.5p3 says it's possible, but it's not obvious how.  This could
probably be addressed by an example.  It would be helpful to include
"assumed length" or "assumed length character" in Table 8.1 and 8.3.4p6.

> > 8.3.5.7p2, description of "lower_bounds" and "upper_bounds": Is the
> > order of elements in the arrays the order of C array bounds or Fortran
> > array bounds?  What is "the given array?"  Should this be "the array
> > described by the descriptor dv?"  Is it OK for the number of elements
> > to be > source->rank?
> >
> No.  But, in C it is not clear how you would ever know.

The C program might not know, but the C programmer could know just by
looking at the text of the program.  C programmers can't designate an
array section with the lbound:ubound Fortran notation, so one might be
tempted to conclude that it is actually necessary that the argument has
the specified extent.  i.e.,

CFI_index_t lower_bounds[5];

can't be an argument if the "rank" member of "source" is not exactly 5.
It seems to be harmless if there are more elements in the array; the
procedure just doesn't look at them, so they don't even need to have
defined values.

The same reasoning applies to arguments of other functions that are
described as having an array for which it says "the number of elements
shall be source->rank" instead of "the number of elements shall not be
less than source->rank".

> > 8.3.5.8p2: It's not obvious how (or even if it's possible) to select a
> > substring of a character array.
> 
> If it were not possible, the elem_len argument would not be part of the 
> formal parameter list.  The displacement gives the offset from the 
> beginning of the character array element, and the elem_len  gives the 
> length of the substring.   The maximum size of the elem_len should 
> probably be source->elem_len - displacement*sizeof() for the type.

An example would be helpful.

> > 8.3.9p2,p3(1): "BIND" should be "BIND(C)"
> 
> The name of the attribute is "BIND" (5.3.5 in F2008), and the text being 
> replaced in F2008 by this text currently says "BIND", so I disagree with 
> this.

This question came to mind because of a remark I overheard at 196
concerning BIND things other than BIND(C), perhaps in Cray's compiler
(or desired to be therein by Cray customers).  IIRC, it was BIND(UPC).





More information about the J3 mailing list