From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by sourceware.org (Postfix) with ESMTPS id 8A0EF385840F; Tue, 5 Mar 2024 21:37:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8A0EF385840F Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=gmx.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmx.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 8A0EF385840F Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=212.227.17.22 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709674660; cv=none; b=Ji1NdXS0ZWoqRXwniczsKguqeSXQ7P8j8hEvAzOy3eboA8iJgNx8yeHvum+dMsAcVw/WgvFt3TYQwBpu3oPft9zsJ/bGP3mXT1IQ8cL5ls4FeEWGmjTVU9ArI4ktOn3fEzhrbJfOv3XjAqkk6n22fPa9N3+dcf640LPJ0JOUM3c= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709674660; c=relaxed/simple; bh=fapIc+PCwDOUXj5VTxPvVhH08sgHIztF2tkyatUvA7I=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=h9fboTOitTFAb6uYmhIjq5sspGjRiXXo/kohgqPsNzVBYgRg86eqBRyY93AlNj8/jITjt/ocxnE+aSiXd02ATGZOgfsLP48NAn2KSkGDBKugFgI+kFfwWm63f3aYYrj1qg0vN9fr92HUegsZKePBCxf2aGeLDYjxF7VJH3YvZP8= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1709674652; x=1710279452; i=anlauf@gmx.de; bh=fapIc+PCwDOUXj5VTxPvVhH08sgHIztF2tkyatUvA7I=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From: In-Reply-To; b=HoHZn5wf9oZanFrmYzNv+/usnAxVKqu6BzGdX376ctWMoOt8nolgzAHSLHDgAhi+ jxvbs28ZwfVQZ+BYqQkFmNyh5tpheCaXE+O6JDQVcqyyghNP0bSdXLuxtFNMtRtpU Xm0IEix2ZD+LTSaTme9+Bwq7nnhhIsSKlp1kzgH1p0W70MgjXr4+HK1VXPPh2GLA3 Jzu+H8ZuhMj6WiXyGnhXU0SQXhpFJKEYTPWuJoAVEJ2sGV6J0mnWQxV/ruU9RIWOL 3QNt/X42SYjsM5Ao2lEGeZpHuW3BP3agv0TDc7vPj9nT8CBNDNnAe3BEfvXKJUWLp dsoFFIel1iBrZn6bFg== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [192.168.178.29] ([79.232.148.95]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N1Obb-1qjNM83lkZ-012mfc; Tue, 05 Mar 2024 22:37:31 +0100 Message-ID: Date: Tue, 5 Mar 2024 22:37:27 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [patch, libgfortran] Part 2: PR105456 Child I/O does not propage iostat To: Jerry D , rep.dot.nop@gmail.com, sgk@troutmask.apl.washington.edu, gfortran Cc: gcc-patches Newsgroups: gmane.comp.gcc.patches,gmane.comp.gcc.fortran References: <943c3685-c4d4-4f22-8b65-6336f8770043@gmail.com> <20240229104705.62e46010@nbbrfq.loc> <033ebcdd-6e25-4af7-9012-3338978751d8@gmail.com> <05A1AEE6-6A68-4D4F-8BEA-6E87969E19E7@gmail.com> <65b13e02-bc1d-4cad-98cc-cf5d6090b742@gmail.com> Content-Language: en-US From: Harald Anlauf In-Reply-To: <65b13e02-bc1d-4cad-98cc-cf5d6090b742@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:9UGLFI6Ud2zSuSt/hWTwWH4y/vxQIHqR5a0orpIFo7Ns1W8YVFT RM/UkJH15anRMganxWFGgL4n42lmTid2iogzjI2+ovUkh2+GrZG6lqSI6/1djbWek+wBqdi HgX4MfIUUzWOClSylb5YZ3sYJkxrUQ7Uikk5VlErp70duundp9BaomlTSkw5QvnCb0fCrQx YyX9Q3en4+8RHQwxc5jzw== UI-OutboundReport: notjunk:1;M01:P0:dY6E+1yi1Zo=;I6sEVtybB/IBLbiZ5ESE3wR2mCB dwhVLf7E5to070IDbzzb832vgNOu5Xq9pIOESNeL3XQRN5jGCmF48Nqvde2jdUpOKYHYRorQb 9GO5e4KizKOotpvHN+FTPtd6vI8u/JsRJuEvlcXfnVAA9saQ0xfQkHzdQiVtMy06yrMmmfQPT P6qtC+EZwpKlWF+CFeUa3M0HUg6UW+K70/rsq5oyv+vlfqMBIdGdRHwP6sWkuVlZyCOZ/IRxF t5egane5qwmAuBHfoInHO1zGOm6ZGlzk2b9xmc75+Zjn21HUbxx7nfLWX1w+VCu2YRNNOPwxs trV/DalRVwA3OKo5F3xJN6WKjFPLF1g0FqFPIb4ZyhZ3VsjABF5a/TDvJG+5sPNXFgKa/f2PK VvYsG01zKh/PONfd6/cRBrSObx2qP1pQP2buBb6lyfYO3uLVv9lHCnzg4zm+EWhW1oCRfB9J/ tXA14Nl6jk4UsinGWAZsOvmEC01Jm2yplKCs59yTT9atcbfRoagjtgMiEPiUj96vTQdtEui5L kXc52L8drmYcqbJX7Ffs+VyO6OPtyx/z/MnTApJRWa4W/fXzCm/TtXlvZbYTmzRY+c9MPlFfl Qb7IgXe95HQobP01Gja0SA4WTUcwQlKRK3u5UIPfeZMW0ZP0EVkOs2yOlOYWbKrM4yQeLioFo SC6ityNFmmsrQAydrKhXWA19EG1SNqQztIWwMCF1IVWsQEWDjNYp15/IMq0jOcAOyIyRvD0UP 5bxnneCQDUYGn6kIUfmmnldXId+iRK93ra98qJTq2zCyWvyN7DIa3BUugxNExIRwFBlyg0xGv qYkcMW9eWJZpuuedqyRbqFkeuLDnRBml32N35LoYbc+ag= X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,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: Hi Jerry, I think there is the risk of buffer overrun in the following places: + char message[IOMSG_LEN]; + child_iomsg_len =3D string_len_trim (IOMSG_LEN, child_iomsg) + 1; free_line (dtp); snprintf (message, child_iomsg_len, child_iomsg); generate_error (&dtp->common, dtp->u.p.child_saved_iostat, plus several more. Wouldn't it be better to increase the size of message by one? Thanks, Harald On 3/5/24 04:15, Jerry D wrote: > On 3/1/24 11:24 AM, rep.dot.nop@gmail.com wrote: >> Hi Jerry and Steve, >> >> On 29 February 2024 19:28:19 CET, 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 2= 55 >>>>>> 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.=C2=A0 In fact, if the >>>> iomsg-variable has a deferred-length type parameter, then >>>> (re)-allocation to the exact length is expected. >>>> >>>> =C2=A0=C2=A0=C2=A0 F2023 >>>> >>>> =C2=A0=C2=A0=C2=A0 12.11.6 IOMSG=3D specifier >>>> >>>> =C2=A0=C2=A0=C2=A0 If an error, end-of-file, or end-of-record conditi= on occurs during >>>> =C2=A0=C2=A0=C2=A0 execution of an input/output statement, iomsg-vari= able is assigned >>>> =C2=A0=C2=A0=C2=A0 an explanatory message, as if by intrinsic assignm= ent. If no such >>>> =C2=A0=C2=A0=C2=A0 condition occurs, the definition status and value = of iomsg-variable >>>> =C2=A0=C2=A0=C2=A0 are unchanged. >>>> =C2=A0=C2=A0 character(len=3D23) emsg >>>> read(fd,*,iomsg=3Demsg) >>>> >>>> Here, the generated iomsg is either truncated to a length of 23 >>>> or padded with blanks to a length of 23. >>>> >>>> character(len=3D:), allocatable :: emsg >>>> read(fd,*,iomsg=3Demsg) >>>> >>>> Here, emsg should have the length of whatever error message was >>>> generated. >>>> =C2=A0=C2=A0 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? >> >> Yes. There is some odd hunk about discrepancy of passed len and actual >> len afterwards in 22-007-r1, IIRC. Didn't look closely though. >> > --- snip --- > > Attached is the revised patch using the already available > string_len_trim function. > > This hunk is only executed if a user has not passed an iostat or iomsg > variable in the parent I/O statement and an error is triggered which > terminates execution of the program. In this case, the iomsg string is > provided in the usual error message in a "processor defined" way. > > (F2023): > > 12.6.4.8.3 Executing defined input/output data transfers > --- > 11 If the iostat argument of the defined input/output procedure has a > nonzero value when that procedure returns, and the processor therefore > terminates execution of the program as described in 12.11, the processor > shall make the value of the iomsg argument available in a > processor-dependent manner. > --- > > OK for trunk? > > Regards, > > Jerry > >