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 D64BF3858C52; Tue, 5 Mar 2024 21:51:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D64BF3858C52 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 D64BF3858C52 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=1709675468; cv=none; b=BxGB0hdYlxgh0nm9qCxF07s03Xdj2Xo0y80ptoCrLIQo+nrF4iPls8ZslkTa0nxB5Qvj0p2YDxJI9C4eGBvJwYcCu1Sy6phmjLN9elvJySlKxKymwHVTpYS65h5g78DDBcN/ay5Oum9PhsoD4c24AaGaCniaV3JO2Fmaj7vTKuQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709675468; c=relaxed/simple; bh=/fhYwqQFTTsq0MflsGWsMh3a3PWaG2l9gqfrq+O6QYo=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:From:To; b=dFvRcokAXW97IH8CdJohDm+nRtBTHcPG81QZRaIvglHK3tGFOvrtrrtxTYcbAdhEIqWa+0zlgs+Ni2kG6eG9w5S4EFPGfJoblTt2ancWf1GzxiJegWKfClxWv40SkXhmFzSoJh07y74Gat39ahxD4rZPZyQYwaDyKOdSOWuTu7I= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1709675462; x=1710280262; i=anlauf@gmx.de; bh=/fhYwqQFTTsq0MflsGWsMh3a3PWaG2l9gqfrq+O6QYo=; h=X-UI-Sender-Class:Date:Subject:From:To:Cc:References: In-Reply-To; b=WnzY+e8XPjLCW9KjTJ1z2uGXC/hTEj8+7iCxlwLfcFqz9Erpvs1QJrvGQ+o3+tMI InI9aIEr3SoOWQNzSRvuk126M0gwkZi2zs7K6MRXLWtsxDQ0Wy6GfX2JiGSMBONfS SzOubdIr2V/iy0MAxHj9IcfKpKl4vZdfnNQLYkhgW+5wKVG6YJxlSmMbJZroAL8Bl 2NF78jFV/Fso7c6cXw4aJmoWuatF0Ayu9uSBIGZ5n2Cv6mg5ZG8RkYUgM6A2cwzR0 CYfwA5BIwH1ZqZzoSbNkeqOdE6FTcI7M6aWwYFGkqqgYD8nIYHl4IbnloExYoZo/q yzpjHpjvusYF4bLkFg== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [192.168.178.29] ([79.232.148.95]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MUXtY-1rHKNS2oVc-00QSyW; Tue, 05 Mar 2024 22:51:02 +0100 Message-ID: Date: Tue, 5 Mar 2024 22:51:01 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [patch, libgfortran] Part 2: PR105456 Child I/O does not propage iostat Content-Language: en-US From: Harald Anlauf To: gcc-patches@gcc.gnu.org Cc: fortran@gcc.gnu.org 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> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:6B7j8sU7qT2/TEdopLKwmP9itemwfdqvMSSKvgjFXLYU7/zC/MI IucuIyVSdFD0pU41j6hJNnkcTow7UlT5PzW+5pdMybz2IH39JIlD3bwYnRs4AV6lzrZG9ht BgUquYmw/XZ+oCpMaQSWujffvCyWZkAmZNTg2BRShaO4mHUeU4bCpAlU9Zgc2cUOHMW/l/a z+M5ZUiPUrXMTPbZ8DAxg== UI-OutboundReport: notjunk:1;M01:P0:ux/5cmurMT0=;ANuIq2T8yndqbQzmcnaOYBalDqM Cv/EWGZ98/W/HKfOl6z0SaHHoJqBi68ugMko1ncrbfCfDfKpTPrmwfy5vR6I3d2tgqW0f4VhS JuHbE8ALZQz0ufv7PobtAhCH1hChz08nvBgjdZkGIDc7JCLANNx1OcvZo3vHssNniCmoj9RJU DmELPgUEDvCTNQPw2fxHT89SCsjEzLKcetaDHMHLjEhtDoESNRW7+O0piy/wHmHFgz6nn26av bc5DU5Fimpx3Hg4sj09o1Ro1eYSULg13uaKp5Zjff+dRMP4/9PMpQFJTTNNI+ZVUkAd055NE2 suwJYusujGLIwW8DkRvXKe0d4njaoXS4DuvamBZSKC7I4tH2V2Z0Nq7a++2HHegIC3tth33Ll cl1+KtTobVzXWb0+NKomm/xwwxfzbd1Ky4eabYtw7ynHeKbxG0/2hsIOdZ1GrA1AOTDdWdJPi SbsknZg2shxhY9ivLQnGe2Ie0Br2aucvRsTnqdbh23c9CSdemuGBQHWmppEIzyn0NYtFpcZ+6 2rBL1XAt1meFUt00iTtRXSfv1uadKoaYMYZGozm1NQDKvv5LyGfxcNMibSB7Qk+rjgnxEBOJ+ Z4oucJIJzrn1X57/aD1qYMud4DlyTZJ2G1xZMzN/pPQUUCFqpIpaTNZ17ZML1uP3YqVhBA21w 6H6fqlKriBHfDPn5CT1vevIW1+ORsQ6XaaUBWQE3d5Pmjl28Lo/9af1hBrnRoz+LYeQwxGOQO 9sWBEXteGeS66bGGhfNUXmOOwGnnnFg4bJZziUeXAvKnLpK4tDJmq36+nPpSdrj/7Txdsm7He hR2WzwA/aDJbkz+zIAKW/c61TQLFhXUIVImAtQpUNmmzE= X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00,BODY_8BITS,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, on further thought, do we sanitize 'child_iomsg'? We pass it to snprintf as format. Wouldn't a strncpy be sufficient? Harald On 3/5/24 22:37, Harald Anlauf wrote: > Hi Jerry, > > I think there is the risk of buffer overrun in the following places: > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 char message[IOMSG_LEN]; > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 child_iomsg_len =3D string_len_trim (IOMSG_LEN, child_iomsg) > + 1; > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 free_line (dtp); > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 snprintf (message, child_iomsg_len, child_iomsg); > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 generate_error (&dtp->common, dtp->u.p.child_saved_iostat, > > plus several more.=C2=A0 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 >>>>>>> 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.=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 condit= ion occurs during >>>>> =C2=A0=C2=A0=C2=A0 execution of an input/output statement, iomsg-var= iable is assigned >>>>> =C2=A0=C2=A0=C2=A0 an explanatory message, as if by intrinsic assign= ment. 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 >> >> > > >