From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by sourceware.org (Postfix) with ESMTPS id CC4C63858C53 for ; Thu, 29 Feb 2024 20:56:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CC4C63858C53 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=troutmask.apl.washington.edu Authentication-Results: sourceware.org; spf=none smtp.mailfrom=troutmask.apl.washington.edu ARC-Filter: OpenARC Filter v1.0.0 sourceware.org CC4C63858C53 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=128.95.76.21 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709240179; cv=none; b=U+rs26M9c7exuCDCszLMJKg8cmXrFBExjOJb9xvAHVlk12b3QCqIC3dxzWBXaGQx2Z9qbHVmVb2GIvTieAl5IlFAesINQRhKks2gQMerqboOjpYsM3xXb5KfHepzDV9M+mucv1WXjV8ZEN0uOvL9z8wgMYFg/sQzXz8AecflUT4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709240179; c=relaxed/simple; bh=hWush+xrtEMgaa8oHqjhJk46zrYo/etFKkA+qTn9H9c=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=d58LTSG82FdiFpND4LDWxe00rqfJds+S+ASd/n0K+GNDWb6QU/CjVZqdrDM0cFEpEgah32WRX+o/s6jh99JDjdMAMn1x8DSXskVHM226+3oZXXohQHtQmsRtqse4PhJ+u2QrjDZKrIo+fGp/T60pQEYo3njgMT7t8KInKjavW8E= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.17.1/8.17.1) with ESMTP id 41TKuFhn025024; Thu, 29 Feb 2024 12:56:15 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) DKIM-Filter: OpenDKIM Filter v2.10.3 troutmask.apl.washington.edu 41TKuFhn025024 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=troutmask.apl.washington.edu; s=troutmask; t=1709240175; bh=hWush+xrtEMgaa8oHqjhJk46zrYo/etFKkA+qTn9H9c=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=lZ2/RZJaMZIZQRPU+BQgMCiajCZO9mtcjAT6TPfv+3T5NBBYqFodt1+0nNG3wKzae jh4535CEud/hXoWs09s0g9U0haAn59D/Bk2DIPogEo4oDaGGtivysrIHWunQgV/Uvy dCYENRZqpVWVf0W9JzW+re3f1bUqm3cHXB074a9p1zb6gnCnwvXSjP3OMcCSDel4jQ TMOxvB6fzG+daXd5k0WEXE2CuS0jl6XI3akBW+hGrhWv+nLXWw9LEmLjNgO5tuwGqv pRFIzN/wINw++IJ8DgWLulRPqJKlH47rMpnbPH2pZ7242fY9oTwoJiSyEV91q27xY/ S0CdcrRUeyTdQ== Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.17.1/8.17.1/Submit) id 41TKuFwb025023; Thu, 29 Feb 2024 12:56:15 -0800 (PST) (envelope-from sgk) Date: Thu, 29 Feb 2024 12:56:15 -0800 From: Steve Kargl To: Jerry D Cc: Bernhard Reutner-Fischer , gfortran Subject: Re: [patch, libgfortran] Part 2: PR105456 Child I/O does not propage iostat Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: <943c3685-c4d4-4f22-8b65-6336f8770043@gmail.com> <20240229104705.62e46010@nbbrfq.loc> <033ebcdd-6e25-4af7-9012-3338978751d8@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <033ebcdd-6e25-4af7-9012-3338978751d8@gmail.com> X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,DKIM_INVALID,DKIM_SIGNED,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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