From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) by sourceware.org (Postfix) with ESMTPS id 4483A385843A; Wed, 6 Mar 2024 04:06:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4483A385843A 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 4483A385843A Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::331 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709697976; cv=none; b=HpJ4Z0Cv+htRvWpdD4GsnSONb4LOasDmor9jfOfVdpSiVadVMTjoGqm9/3QrBFygWu8TR3rvRtiXtb1duZ3/APw8ulWCQBcWLRwdqXOKRCYJgj0fUdr0P6AYPJkZ0lJixUCO95CJkBJlTsVJFr+IVEb/GxbdDa7fxEew6IjElw8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709697976; c=relaxed/simple; bh=kN9rEYc71mAbK9tkV5K/SbS7vmlUPFXttlWqpi3E2Qs=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=vR0PgxUpW05FoaOE0MSOVg5m1o307x/Q3NWd34YTR4oWoZ1YXPBZuXE/nuhffPLCCsnpI914SKxTEMnaR0PEGe08uzuFdNISaBsfW4scY3g0t1NERwnV8ZrCm7fWX9seZmPpM8yRwhcCTd5h494ry4rysykvCHe50REs6LADoXY= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ot1-x331.google.com with SMTP id 46e09a7af769-6e4ea48972cso915225a34.0; Tue, 05 Mar 2024 20:06:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709697972; x=1710302772; 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=wzoqn5quGF/ALkrkqYR2uMVMEFyilLhIilfnSh+iPMQ=; b=VhqRbE0OXwA4GA7TQ40tIx87qwDtb+ndb7PLmIqdj3lE+juLmx8rXUde/e6UVFszXT JFJM6EYAjgyEcu6OXwmg90UNd10rVZ+WmJ/KJ4ju5FKI5ZSvBLv13SDG48mY0iZHq3I/ 9+9xEiLz4m8FOiDq4hg3NcxCrCV4ySwxmpb39FVI7PS+gq26nWbZ/MkXDRZohqDDiOpA tWAgHhAm59nNySQiSVZQ38w/nFbY3Rvr39XPJpBcfnQdkbGn01XkcksHevELOaq80weY BmiAn3eV8HB0rF1PVZGAcMvUttHmL8wHX/251mOXv5XFdGquHU1wwGP7Ss/R4koUtnTR 1tXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709697972; x=1710302772; 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=wzoqn5quGF/ALkrkqYR2uMVMEFyilLhIilfnSh+iPMQ=; b=oviI5/gZ5tXDwr8yMqG8SuOA+UnHilovet0IANJ9cpAz9vs+AMhX9oixhS61znc6ki x1zFn7aq3BGLACXPq77qzo7mI3msdJNThRZzqIyr+Ig1rvPC2+0RhvZmiPs+E4IlVCed r2L2JhWgfEydUEECvBKWyhzvv9WflRX1pEhBcnWK+I3HQpn0vLy4ocS6zv4f5yDI70/i Us6dSkXQUBXNT7a7R4QZLchVEWbw6NC4+UwtWkT0vw5tvIUrRWMMhEEbVxS6MFsZhOux bOVzSKoupvmA3j0lU0498ldBzh6tIg3s212DTKhp+z4911qg5duvPtW5mPCwyKEBk2Va r+sg== X-Forwarded-Encrypted: i=1; AJvYcCWOa5GxenFa9vUeBT0ScroTJbhVGIhvHaxDxgO9TVWOd6Wq23tuKWowr/C4hXFyU3mrM19xlzu1Vg+xnGSOH97cxCBF/BLYsw== X-Gm-Message-State: AOJu0YxgyrmhzsyGaYqvNkj8S5X0Ck0wENad75wEK7Os16fYj9uw3xjp UckkQ//QZSeLRseqPmlbR1w5+ubVqKEJeVB+mG5BkrarIUIqP9PJ X-Google-Smtp-Source: AGHT+IEvXOcinuDGpAsEtOmHbVEkT0CTr6CO9U8MfKCd4lHkuKpJh2+TKkAOXAF6uESlT2LuwIQ/ug== X-Received: by 2002:a05:6871:7818:b0:220:be2c:6087 with SMTP id oy24-20020a056871781800b00220be2c6087mr2549504oac.3.1709697972280; Tue, 05 Mar 2024 20:06:12 -0800 (PST) Received: from [192.168.1.20] ([50.37.177.113]) by smtp.gmail.com with ESMTPSA id a30-20020a631a5e000000b005d30550f954sm9938438pgm.31.2024.03.05.20.06.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Mar 2024 20:06:11 -0800 (PST) Message-ID: Date: Tue, 5 Mar 2024 20:06:10 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [patch, libgfortran] Part 2: PR105456 Child I/O does not propage iostat To: Harald Anlauf , gcc-patches@gcc.gnu.org Cc: fortran@gcc.gnu.org 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: 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: 8bit X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00,BODY_8BITS,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 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 >>> >>> >> >> >> >