(j3.2006) Questions about unformatted write

[Malcolm Cohen]

Ah, looks like I can post to the list again.... I wasn?t really expecting that!

...or I would have been more careful to copy-paste the correct bullets:

An effective item of derived type in an unformatted input/output statement is treated as a single value in a
7 processor-dependent form unless the list item or a subobject thereof is processed by a defined input/output
8 procedure (12.6.4.8).

If a derived-type list item is not processed by a defined input/output procedure and is not treated as a list
14 of its individual components, all the subcomponents of that list item shall be accessible in the scoping unit
15 containing the data transfer statement and shall not be pointers or allocatable.

i.e. the prohibition is in the same sentence that forbids allocatable and pointer components.

Cheers,

From: Malcolm Cohen 
Sent: Tuesday, October 17, 2017 8:45 PM
To: fortran standards email list for J3 
Subject: Re: (j3.2006) Questions about unformatted write

It?s not hard to find:

If a list item of 1 derived type in an unformatted input/output statement is not processed by a defined
2 input/output procedure (12.6.4.8), and if any subobject of that list item would be processed by a defined
3 input/output procedure, the list item is treated as if all of the components of the object were specified in
4 the list in component order (7.5.4.7); those components shall be accessible in the scoping unit containing
5 the data transfer statement and shall not be pointers or allocatable.

From: Van Snyder 
Sent: Tuesday, October 17, 2017 1:55 PM
To: j3 
Subject: (j3.2006) Questions about unformatted write

Consider this program:

module M
private
public :: F
type :: T
private
integer :: I
end type T
contains
type(t) function F ( I )
integer, intent(in) :: I
f%i = i
end function F
end module M

program P
use M, only: F
write ( 42 ) F(11)
end program P

Two of my three processors prohibit the reference to F(11) as an output
list item, and give the reason that its component is private. I can't
find where that's prohibited. Another processor is happy to compile and
execute the program, and produce output I might expect. The two
processors that prohibit the reference produce the same output file as
the third processor if the component is public.

The third item in the list in 12.6.3p7 says the derived-type object is
treated as a single entity in a processor-dependent way.

The second item in the list says that the components would be treated
individually if objects of the type (T) are not processed by a defined
output procedure (they aren't) and any of its components are processed
by defined output (but none are), so this list item doesn't apply. This
is the place where it is required that the components are required to be
available.

With public or private components, I don't see how it can work, since
the processor doesn't have access to (the name of) the result type of
the reference F(11).

Is the reference to F(11) prohibited or allowed in the output list if it
has a private component, given that the value is treated as a single
entity in a processor-dependent way? I.e., which processors are
correct? I couldn't find anything relevant in 12.6.3. Is the
prohibition against private components in a derived-type list item that
is processed as a single object somewhere else?

And how do the processors that complain about the private component know
it's private if they don't have access to (the name of) the result type
of the function reference?

And how do any processors (with private or public components) have
enough information to write the whole object, given that they do not
have access to (the name of) the type?

Do they have access to the type, even if its name is private? If so,
where do we say so? I couldn't find anything relevant in 8.5.2 or
14.2.2.


_______________________________________________
J3 mailing list
J3 at mailman.j3-fortran.org
http://mailman.j3-fortran.org/mailman/listinfo/j3



Disclaimer

The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business.




Disclaimer

The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business.



--------------------------------------------------------------------------------
_______________________________________________
J3 mailing list
J3 at mailman.j3-fortran.org
http://mailman.j3-fortran.org/mailman/listinfo/j3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.j3-fortran.org/pipermail/j3/attachments/20171017/8600a661/attachment-0001.html>