From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) by sourceware.org (Postfix) with ESMTPS id 2EF003858D34 for ; Thu, 29 Feb 2024 22:28:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2EF003858D34 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 2EF003858D34 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::632 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709245729; cv=none; b=SWvDKUIDDG6rdzHNCeqI+6+MC7D0EBuwf3Cgvlp7m+0iojogurT6dHC0nb5tOGoimGql46HwcpjxbU5jWlgmiTM4/Q4+J7ywoWuMCPvw+uNcfY2Bi9xXRD0w5AIqesDPcw4NBqXxZJ7j8huN7o8HPDayTT2HttuFrk3UQzcSSAo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709245729; c=relaxed/simple; bh=8E8Lxe0u8GAOiQ4276wX0Kt3fi6NSOsgG0Lut0BcWhc=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=vlRcBRGcHRQlcc4Vfws1Wgvy61tDOKpheBI0Y69CBc8A501X/U39cZCQULLup2LqX4QjQsXA2hMMcBKh/xFZ7XnwotMno+AAAluin6+7QTdYaggLbwvHpxib+TGxhb2k7CLXtsjokHIGYQ5qq3BcUa0kbS5jt+GiqmwjQPiwlL8= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pl1-x632.google.com with SMTP id d9443c01a7336-1dbff00beceso2553645ad.1 for ; Thu, 29 Feb 2024 14:28:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709245726; x=1709850526; darn=gcc.gnu.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=q7BhL02wDlkQQctYgwUYhM2zwMSyy5tis8f7F70ok3I=; b=ApZI3KVhge1zad37vGLJr7L79bHuKbvvWmpe/V/udIiNL1dCyTNQn7b1b3NKak3g5V Wkb/vC7AN/nPx2xQ5CMS/iwptlhLaqlQcfpF0HV2tMKEGjzKi1761PoTrAcCRzrzcjwm YzpjPOFO3f2HEeoBgs3XqcpdD7LTAK8KjMvrdrJPipMWJAoQd9lB8XdaAfutTkvKv0hT 6d0R4UzhHeRBtbHAtMPWiMbcZyavoNAG6FQzUi3Pc0dQKO2E/XKIrwJayKqRQoljMeoo TNNmTgSD2m34Vp5b39zLZbisu514NgKLyqe+gGFwvSPNrKvHagdvMwa+kAsEWqo03atp UVgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709245726; x=1709850526; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=q7BhL02wDlkQQctYgwUYhM2zwMSyy5tis8f7F70ok3I=; b=IBDj+CdNHOdLWfXqStMYVQYg+q3fZew5iGV2MM/UGU5TzBILo+J18igoCCh5ljGFHx yobB8K9kQsHGTUoydDL3pTLuLLPsl0e+V4r2nphtpUXrUl17EFk0SAA0nJwM5U2X63/g nYRIMnzeOByBDqYuxDcQNVchDmzEfOhpKMD4waBKrEu6adoqoCi53BQtpd2eE4kgScK7 lG2+v/FsJpmtkAxcYR3GUEIXDy+Q0+7e3C2UYxX8kWn9N1zjImk5AheVXkaMqoDvtNiS 7heITQvdwYHomuj5gu4iluCuZUblzIOEp9JuTNchr+gljdUiUtVUn0RDNFpPWDSwxHai qtOw== X-Forwarded-Encrypted: i=1; AJvYcCXebyxmIo57SZ57gXzD+TOdnU36aeJ/+T1fKrh8mpj9CpUOdrBOQBCqkW2xEcmiAHALONgM5IE7PO0NhvkHu6Vqa2YY X-Gm-Message-State: AOJu0YzbxxoMk9Zl+dCfslY4pga/yqyRqMexHznpZKKxlBeSSiDN9Do6 G8ZzxG7zeAexUhRGXlqcmvqozQ6HXl4L9xGALNLwRTle6WALNWMK X-Google-Smtp-Source: AGHT+IESebb+2vrGP3waLOlDl/qXqKErBlOmOZUS4S6Neuzv5OVbPksMBrkrJinlKcPWdERVNpNikw== X-Received: by 2002:a17:902:9688:b0:1dc:6208:2e5a with SMTP id n8-20020a170902968800b001dc62082e5amr3521282plp.3.1709245725735; Thu, 29 Feb 2024 14:28:45 -0800 (PST) Received: from [192.168.1.24] ([50.37.177.113]) by smtp.gmail.com with ESMTPSA id f7-20020a170902ce8700b001db604f41dcsm2033508plg.103.2024.02.29.14.28.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Feb 2024 14:28:45 -0800 (PST) Message-ID: <5e5653eb-aeea-4eec-be52-a5adea71b201@gmail.com> Date: Thu, 29 Feb 2024 14:28:44 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [patch, libgfortran] Part 2: PR105456 Child I/O does not propage iostat To: sgk@troutmask.apl.washington.edu Cc: Bernhard Reutner-Fischer , gfortran References: <943c3685-c4d4-4f22-8b65-6336f8770043@gmail.com> <20240229104705.62e46010@nbbrfq.loc> <033ebcdd-6e25-4af7-9012-3338978751d8@gmail.com> Content-Language: en-US From: Jerry D Autocrypt: addr=jvdelisle2@gmail.com; keydata= xjMEY5TlkxYJKwYBBAHaRw8BAQdAyrkRDhmJhSTTlV/50gJLlvliU6/Lm5C9ViKV8T9y1GnN HkplcnJ5IEQgPGp2ZGVsaXNsZTJAZ21haWwuY29tPsKJBBMWCAAxFiEEOFR0TS0390uh8dRV uWXAJaWpwWoFAmOU5ZMCGwMECwkIBwUVCAkKCwUWAgMBAAAKCRC5ZcAlpanBalsJAP4wdCiH 2Of9oZv1QWgZ/AVdbWFM3Fv47/WZQHOXfoZ9HgD6AkXrKeJ+6usST7PEaDJjptaViT1fLiYY V/6XaOKSsgLOOARjlOWTEgorBgEEAZdVAQUBAQdAdA7PczYnl07vnOT9oP/wvvMDd4HP09Zl g3LzwXQJWT8DAQgHwngEGBYIACAWIQQ4VHRNLTf3S6Hx1FW5ZcAlpanBagUCY5TlkwIbDAAK CRC5ZcAlpanBasF/AQCa5WjlsVpLsEiggZyT18MOJNAdeRd7wkGDUrwedHrvawD/cE1H+/Ms L1ZwvQiLfGdx8crigQqWTQyos4kH8Wx82wc= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham 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 2/29/24 12:56 PM, Steve Kargl wrote: > 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. > > > Without addressing the length discussions above, I did find an existing function in libgfortran to trim the spaces at the end (string_len_trim). I am using it as follows: if ((dtp->u.p.child_saved_iostat != 0) && !(dtp->common.flags & IOPARM_HAS_IOMSG) && !(dtp->common.flags & IOPARM_HAS_IOSTAT)) { char message[IOMSG_LEN]; child_iomsg_len = string_len_trim (IOMSG_LEN, child_iomsg) + 1; snprintf (message, child_iomsg_len, child_iomsg); generate_error (&dtp->common, dtp->u.p.child_saved_iostat, message); goto nml_err_ret; } I will study the len questions further. Jerry PS I wish my mail client would not wrap text on me, working on that issue.