From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by sourceware.org (Postfix) with ESMTPS id AD0713858D34; Wed, 6 Mar 2024 17:13:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AD0713858D34 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 AD0713858D34 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=212.227.15.19 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709745193; cv=none; b=cTK0haXX88wB/UwLcPUeCk40FgyPLB1Zoi/KKFr8sA+RTFcyZnaE2IJdExHIPUS+f0YFmFB3glTve8Z2Rf9XfP5X6dwNT9YLKvNtdfZGlToCZQISiUlqeL5x2arYOhY2sSzzYKmiju/hKhzTT4ek8HLWdcgDfy36DMMYXlhpLmM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709745193; c=relaxed/simple; bh=DHBlBdcO38YSy6MrgXueEYp+LUbfRpeS0qvwwHNFEDk=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=x+qDdmE0WKPT1JS62KVda6hUYUHGuHXtP5RnM7uoKvyuA/cZRGaxalyYhUPepoYngRRFBAsUssJC/HAsSFT5Br87c6Wn7o9gv20gbBw5931RgMDryXya7j2diepCmC/wdInslQmf6ctI9rzw2A7ahEtzUmTMW4gzwmgzN0bKNMY= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1709745190; x=1710349990; i=anlauf@gmx.de; bh=DHBlBdcO38YSy6MrgXueEYp+LUbfRpeS0qvwwHNFEDk=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From: In-Reply-To; b=DmT2EGmKdOMdza4JLupeEmEqwlbObF+n22tvMNTTgrKgcT4zcGcPCatjjp8Ie5XB fUfwRK1m21yL/p3raBuOaVWyMTTX34xQnjS4cHqPlifK3wzwd1tYpqv1ybXDPnRz+ YCA9vWY6PORs9T2hEVWm0EJRPH/4asuzxZyWqBRbGQY9/Aj02O57sbVFDGAKEMRJV haIg/rFUyQnNDMNsaC7R5dmEbI4UZEWUONQmc87EvFLX/0+WSgeoMSVAUmwavunt1 XuPxdbV6j0k3oVlYzrrX/kclnsymwbOxlkofvSYsiHDpN0e05JF5JNWpeK3Nltulx E/oyxKIBiMXpTUYOhQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [192.168.178.29] ([79.232.158.97]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N9dwd-1qo0Po3gE1-015YbR; Wed, 06 Mar 2024 18:13:09 +0100 Message-ID: <466d3d24-8795-488d-96ac-edb2fc04676a@gmx.de> Date: Wed, 6 Mar 2024 18:13:09 +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 To: Jerry D , 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> From: Harald Anlauf In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:sRVBCnmu1wmsiu0nfRq2Crzm88OZ4N+0PBEs8ZvAkg8hTFu1YQ+ MabfjwB80SrVvlMBzOZ++q1G+Hp8l2ZbHu9zBQUb+SUjnA7gJX7Z3ejtBSk1KW2mN0ZPfcu GIKINnPmlxpYSVAvpYCvqFoYri1CmfSllk1Nifgu2PCUsSmocfy0eBXHta0qfpMBvOi2dJD M9cCp91lYbAnKCzipgWZw== UI-OutboundReport: notjunk:1;M01:P0:olzqIK5+/KQ=;7bteGTEXm6fYFqoZP9YFvDkYd/n nLb8+2vCoAhrWW9ydQGkb4Sr2+39jhX7v5Hn5omVpBIriSb+/7f6I+M6FY5qeCEyzuHLpOKRF 7PRwb8SzY7bLaR4Khjgzm0hGmTLOYRFTnTSOc10efAFku7Cf/A3wcxG0r3x+ao9MjstYf+THi A33sZRtUwiYx6+YnPD8VXeEeptG2AALdu44Uawei/f9xCifXOM89Wp5twpyGHhOt1XDNSHLro qdxR9o0bUUBiOkUbtuYbwPPBd5KmvcB8NMUpLg7o0lMY2ido5XMlFslT+scsZ0TJ3JFTny44L bDZ1R6N4RLyWwUOeoHtBHuwPukfFsAMIGQXb3Qjl9ogIC7LkLAwKOA/G/HbOaNRAyPK4iFUy6 CjoEQAwR85dr0ngrbycVCGCzTqhnO/w1PShy9OatZ4ucZ49nhlvN9B6bIhKE32oY23T/OuGvl QK0ikQ6XxcCVpPX3qQ5QakirR/Jmw1AxTh7f0i6EU5lDUUuoQZGK2O79BF9jpaRDTHtOcZGLV HCXAg9CKGqEPlHNelEt8ftmNSpdWXHB42a9m8UPfZu6L+JbbnLBvcM61JYQREblUrOuiFkCdX YL5yV/tWqMVmoIUfILTLk3mU/CXSDmjbu1/TnnqosqOh2/SOxEkEHwDtB0zeF+RzwqhFTBpDo S0tNIBNqKSh4XuDxMLj3DgoDikIybBtCgi6CjrYKcRG5cUlD4r4/CvJPDAkSbUFxUR07adcW8 +UPZUOGOEgG4B1wc9WenQT95sbhG/1Rvt6OpL9OucH4wvPKYceDYIjA+pU82bZdkRNWhfZjgX IUcchYo2wHsfXtAzjvLIX9x/rMvXok0NCC+GNYznKFzHE= X-Spam-Status: No, score=-3.3 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, can you please replace the user message in e.g. your new testcase pr105456-wf.f90 by say: piomsg=3D"The users message containing % and %% and %s and other stuff" This behaves as expected with Intel, but dies horribly with gfortran after your patch! Cheers, Harald On 3/6/24 05:06, Jerry D wrote: > On 3/5/24 1:51 PM, Harald Anlauf wrote: >> Hi Jerry, >> >> on further thought, do we sanitize 'child_iomsg'? >> We pass it to snprintf as format. >> >> Wouldn't a strncpy be sufficient? >> >> Harald >> >> > > Just to be safe I will bump char message[IOMSG_LEN] to char > message[IOMSG_LEN + 1] > > This is like a C string vs a Fortran string length situation. snprintf > guarantees we don't exceed the child_iomsg_len and null terminates it. > > I added 1 to: > =C2=A0child_iomsg_len =3D string_len_trim (IOMSG_LEN, child_iomsg) + 1 > > Because snprintf was chopping off the last character of the fortran > string to put the null in. (zero based vs one based char array). I test > this with a very long string which exceeded the length and then reduced > it until I could see the desired end. > > I have not tried running a test case with sanitize. I did check with > valgrind.=C2=A0 I will try the sanitize flags to see if we get a problem= .=C2=A0 If > not will push. > > Thanks for comments, > > Jerry - > >> 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=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=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=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 t= o >>>>>>>>> 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 an= d >>>>>>>> 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 cond= ition occurs >>>>>>> during >>>>>>> =C2=A0=C2=A0=C2=A0 execution of an input/output statement, iomsg-v= ariable is >>>>>>> assigned >>>>>>> =C2=A0=C2=A0=C2=A0 an explanatory message, as if by intrinsic assi= gnment. If no >>>>>>> such >>>>>>> =C2=A0=C2=A0=C2=A0 condition occurs, the definition status and val= ue 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 ioms= g >>>> variable in the parent I/O statement and an error is triggered which >>>> terminates execution of the program. In this case, the iomsg string i= s >>>> 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 therefor= e >>>> 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 >>>> >>>> >>> >>> >>> >> > > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ciao.gmane.io (ciao.gmane.io [116.202.254.214]) by sourceware.org (Postfix) with ESMTPS id 0E9BB3857C43 for ; Wed, 6 Mar 2024 17:20:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0E9BB3857C43 Authentication-Results: sourceware.org; dmarc=fail (p=quarantine dis=none) header.from=gmx.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=m.gmane-mx.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 0E9BB3857C43 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=116.202.254.214 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709745605; cv=none; b=jiQdCsrvojEgYnz2vIFZZEzX6/MZ7C0jZ48CpbCNfNcrX870UZ7bz4H2xEFIkU5c3xbXFokphoPRceBIZr7vFjD0YZqx68I4xcBCJIzVEaKIEi+pj0O00y8ovNyUAPomgx2WdcqGpH92W3bndLIQ74Z4Ca98PBDzWNt04O4Yp3k= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709745605; c=relaxed/simple; bh=hMLxRgB+3+Wf77T+AEsWh9oZuWyIBy0BMF80ByDFwNg=; h=To:From:Subject:Date:Message-ID:Mime-Version; b=lKw+pKrlQkAKeKg3do2aTEzs1Ckwu23otsXvAahW8azvMaeU1zPA+YJ8d24knF64d7hUbkDsmW1B9Az3whB3gwQFQP4j0KCtDCNbo3oGaZ8B3Gau52zh0AbyrTwJ2141dSazTXtocsYK8WadFF2ztLqqAfJkQMs6N1+sUUdqq6Y= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1rhuvy-000AC5-Qt for gcc-patches@gcc.gnu.org; Wed, 06 Mar 2024 18:20:02 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gcc-patches@gcc.gnu.org From: Harald Anlauf Subject: Re: [patch, libgfortran] Part 2: PR105456 Child I/O does not propage iostat Date: Wed, 6 Mar 2024 18:13:09 +0100 Message-ID: <466d3d24-8795-488d-96ac-edb2fc04676a@gmx.de> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit User-Agent: Mozilla Thunderbird Content-Language: en-US In-Reply-To: Cc: fortran@gcc.gnu.org X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,BODY_8BITS,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,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: Message-ID: <20240306171309.dRdNtRz61iSUq23OaC_Rqlq5zMWsRN6sOWUJX1HJprc@z> Hi Jerry, can you please replace the user message in e.g. your new testcase pr105456-wf.f90 by say: piomsg="The users message containing % and %% and %s and other stuff" This behaves as expected with Intel, but dies horribly with gfortran after your patch! Cheers, Harald On 3/6/24 05:06, Jerry D wrote: > On 3/5/24 1:51 PM, Harald Anlauf wrote: >> Hi Jerry, >> >> on further thought, do we sanitize 'child_iomsg'? >> We pass it to snprintf as format. >> >> Wouldn't a strncpy be sufficient? >> >> Harald >> >> > > Just to be safe I will bump char message[IOMSG_LEN] to char > message[IOMSG_LEN + 1] > > This is like a C string vs a Fortran string length situation. snprintf > guarantees we don't exceed the child_iomsg_len and null terminates it. > > I added 1 to: >  child_iomsg_len = string_len_trim (IOMSG_LEN, child_iomsg) + 1 > > Because snprintf was chopping off the last character of the fortran > string to put the null in. (zero based vs one based char array). I test > this with a very long string which exceeded the length and then reduced > it until I could see the desired end. > > I have not tried running a test case with sanitize. I did check with > valgrind.  I will try the sanitize flags to see if we get a problem.  If > not will push. > > Thanks for comments, > > Jerry - > >> On 3/5/24 22:37, Harald Anlauf wrote: >>> Hi Jerry, >>> >>> I think there is the risk of buffer overrun in the following places: >>> >>> +             char message[IOMSG_LEN]; >>> +             child_iomsg_len = 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 >>>>>>>>> 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? >>>>> >>>>> 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 >>>> >>>> >>> >>> >>> >> > >