From: Steve Kargl <sgk@troutmask.apl.washington.edu>
To: Jerry D <jvdelisle2@gmail.com>
Cc: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>,
gfortran <fortran@gcc.gnu.org>
Subject: Re: [patch, libgfortran] Part 2: PR105456 Child I/O does not propage iostat
Date: Thu, 29 Feb 2024 12:56:15 -0800 [thread overview]
Message-ID: <ZeDvb_tqpQPIkHVA@troutmask.apl.washington.edu> (raw)
In-Reply-To: <033ebcdd-6e25-4af7-9012-3338978751d8@gmail.com>
On Thu, Feb 29, 2024 at 10:28:19AM -0800, Jerry D wrote:
> On 2/29/24 10:13 AM, Steve Kargl wrote:
> > On Thu, Feb 29, 2024 at 09:36:43AM -0800, Jerry D wrote:
> > > On 2/29/24 1:47 AM, Bernhard Reutner-Fischer wrote:
> > >
> > > > And, just for my own education, the length limitation of iomsg to 255
> > > > chars is not backed by the standard AFAICS, right? It's just our
> > > > STRERR_MAXSZ?
> > >
> > > Yes, its what we have had for a long lone time. Once you throw an error
> > > things get very processor dependent. I found MSGLEN set to 100 and IOMSG_len
> > > to 256. Nothing magic about it.
> > >
> >
> > There is no restriction on the length for the iomsg-variable
> > that receives the generated error message. In fact, if the
> > iomsg-variable has a deferred-length type parameter, then
> > (re)-allocation to the exact length is expected.
> >
> > F2023
> >
> > 12.11.6 IOMSG= specifier
> >
> > If an error, end-of-file, or end-of-record condition occurs during
> > execution of an input/output statement, iomsg-variable is assigned
> > an explanatory message, as if by intrinsic assignment. If no such
> > condition occurs, the definition status and value of iomsg-variable
> > are unchanged.
> > character(len=23) emsg
> > read(fd,*,iomsg=emsg)
> >
> > Here, the generated iomsg is either truncated to a length of 23
> > or padded with blanks to a length of 23.
> >
> > character(len=:), allocatable :: emsg
> > read(fd,*,iomsg=emsg)
> >
> > Here, emsg should have the length of whatever error message was
> > generated.
> > HTH
> >
>
> Well, currently, if someone uses a larger string than 256 we are going to
> chop it off.
>
> Do we want to process this differently now?
>
If I look at the interfaces for UDTIO in F2023 (pp. 254-255),
the declaration for iomsg is
CHARACTER (LEN=*), INTENT(INOUT) :: iomsg
F2023 (p. 62) has
An asterisk as a type-param-value specifies that a length type
parameter is an assumed type parameter. It is used for a dummy
argument to assume the type parameter value from the effective
argument, ...
So, in theory, one should be able to get the required length
from length from the argument.
CHARACTER(LEN=23) str
WRITE(6,'(DT)',iomsg=str) derived-type-entity
If the subroutine supplied by the user internally creates
an error message with 300 characters, then from the above I
would think that it will be truncated to 23 characters.
OTOH, if the user is expecting the full 300 characters with
CHARACTER(LEN=300) str
WRITE(6,'(DT)',iomsg=str) derived-type-entity
then truncating internally to 256 seems wrong.
Now, that I looked at the interface more closely, the declaration
CHARACTER (LEN=*), INTENT(INOUT) :: iomsg
seems to block the use of an unallocated deferred-length 'str'
and (re)-allocation does not occur.
--
Steve
next prev parent reply other threads:[~2024-02-29 20:56 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-29 5:29 Jerry D
2024-02-29 9:47 ` Bernhard Reutner-Fischer
2024-02-29 17:36 ` Jerry D
2024-02-29 18:13 ` Steve Kargl
2024-02-29 18:28 ` Jerry D
2024-02-29 20:56 ` Steve Kargl [this message]
2024-02-29 22:28 ` Jerry D
2024-03-01 20:50 ` rep.dot.nop
[not found] ` <05A1AEE6-6A68-4D4F-8BEA-6E87969E19E7@gmail.com>
2024-03-05 3:15 ` Jerry D
2024-03-05 21:30 ` rep.dot.nop
2024-03-05 21:37 ` Harald Anlauf
2024-03-05 21:51 ` Harald Anlauf
2024-03-06 4:06 ` Jerry D
2024-03-06 6:06 ` Steve Kargl
2024-03-06 17:13 ` Harald Anlauf
2024-03-06 17:13 ` Harald Anlauf
2024-03-06 18:03 ` Jerry D
2024-03-06 18:24 ` Jerry D
2024-03-07 4:01 ` Jerry D
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZeDvb_tqpQPIkHVA@troutmask.apl.washington.edu \
--to=sgk@troutmask.apl.washington.edu \
--cc=fortran@gcc.gnu.org \
--cc=jvdelisle2@gmail.com \
--cc=rep.dot.nop@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).