(j3.2006) Questions about unformatted write

Tue Oct 17 12:15:50 EDT 2017

I note that Intel Fortran is the outlier here - I submitted a bug report.

Steve

On Tue, Oct 17, 2017 at 4:51 AM, Malcolm Cohen <malcolm at nag-j.co.jp> wrote:

> 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
>
>
> _______________________________________________
> 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/fe0ccb2a/attachment.html>