[J3] Question on iomsg in DTIO

Thu Mar 28 14:02:52 UTC 2024

Hi Brad,

yes, I wrote the edits to tightly fit the requirement “treat an unallocated iomsg as being not present”. But of course /interp is free to
make changes, especially if the solution below is considered to provide better clarity.

The initial paper could contain an alternative suggestion along the lines below, of course.

Cheers

Von: Brad Richardson <everythingfunctional at protonmail.com>
Gesendet: Donnerstag, 28. März 2024 14:35
An: General J3 interest list <j3 at mailman.j3-fortran.org>
Cc: Bader, Reinhold <Reinhold.Bader at lrz.de>; Malcolm Cohen <malcolm at nag-j.co.jp>
Betreff: Re: [J3] Question on iomsg in DTIO

Hi Reinhold,

When I wrote my earlier response I hadn't quite put together a couple of bits of information. The iostat and iomsg arguments to a UDTIO procedure are not optional, and thus the processor is already obligated to provide them and handle a nonzero iostat value in the case they are not present in the parent IO statement. Given that, I'm fine with the solution that it is the processors job to deal with tying together a deferred length iomsg and a UDTIO iomsg.

However, I think the edits provided are not quite right. If the iomsg argument provided in the parent IO statement is already allocated, it should be reallocated to the size of the message returned by the UDTIO, not that the UDTIO should use its current size. It seems to me the edits provided would indicate the latter. I.e., the behavior if the variable supplied in the parent IO statement is deferred length allocatable should be as if

block
  character(len=PROCESSOR_DEPENDENT) :: iomsg_buffer
  call UDTIO(..., iomsg_buffer)
  iomsg = len_trim(iomsg_buffer)
end block

whether the variable is previously allocated or not.

Regards,
Brad

On Thu, 2024-03-28 at 11:22 +0000, Bader, Reinhold via J3 wrote:
Hi Malcolm, Brad,

thanks for the feedback. Attached an updated draft that tries to follow Malcolm’s suggestion for resolving this issue.
I’ve also updated the discussion a bit since the processor dependencies appear to be a bit too far away from this
scenario.

Cheers,
Reinhold

Von: J3 <j3-bounces at mailman.j3-fortran.org<mailto:j3-bounces at mailman.j3-fortran.org>>Im Auftrag von Malcolm Cohen via J3
Gesendet: Dienstag, 19. März 2024 04:15
An: 'General J3 interest list' <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>>
Cc: Malcolm Cohen <malcolm at nag-j.co.jp<mailto:malcolm at nag-j.co.jp>>
Betreff: Re: [J3] Question on iomsg in DTIO

Hi Reinhold,

Yes, well we knew when we added auto-reallocation that it was not backwards-compatible.

Brad’s suggestion of allowing allocatable and ordinary arguments to coexist in a generic would need a fair bit of work, as it unfortunately opens the barn doors very wide to ambiguities. It is also not actually necessary to add the full feature *IF* we just want to fix this. And deciding to do this suggestion would be new feature design, and thus Fortran 202y and DATA subgroup.

And the obvious answer here is to treat an unallocated IOMSG= argument as one that is missing. That’s how normal procedure calls work. Yes, the i/o statement is not a “normal procedure call”, but in the end the procedure is “called normally”, so although the words are not explicit (but then much of the new auto-realloc is done by vague handwaving), it is a reasonable deduction.

With that answer, LEN(IOMSG) in the defined i/o procedure would be equal to whatever it is when there is no IOMSG= specifier in the i/o statement. That is already allowed, and the LEN(IOMSG) in the routine is processor-dependent in that case.

Then, to integrate with the new auto-realloc scheme, we just have the processor assign it afterwards (but only with nonzero IOSTAT, of course), allocating it to LEN_TRIM of the returned message (which might have been truncated if the user assigned a ridiculously long message to what is a buffer designed for holding the processor’s i/o messages). The words in the standard already imply this, I think.

The main thing missing would appear to be an explicit description of what an unallocated allocatable means for defined i/o. The rest is, I think, already there.

I note that this solution is not one of your suggested resolution. However, it is, I think, what the features we have imply should happen. As has happened so often in the past, we added a new feature but neglected to describe it hyper-rigorously because “we all know what it means”, and thus missed out describing it properly.

Cheers,
--
..............Malcolm Cohen, NAG Oxford/Tokyo.

From: J3 <j3-bounces at mailman.j3-fortran.org<mailto:j3-bounces at mailman.j3-fortran.org>>On Behalf Of Bader, Reinhold via J3
Sent: Monday, March 18, 2024 8:03 PM
To: General J3 interest list <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>>
Cc: Bader, Reinhold <Reinhold.Bader at lrz.de<mailto:Reinhold.Bader at lrz.de>>
Subject: [J3] Question on iomsg in DTIO

Dear all,

attached a draft paper for which I’d like some feedback (especially from /interp) before I submit it to the J3
site.

Cheers
Reinhold

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20240328/2ac51077/attachment.htm>