From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from impout006.msg.chrl.nc.charter.net (impout006aa.msg.chrl.nc.charter.net [47.43.20.30]) by sourceware.org (Postfix) with ESMTPS id 94BBD3858D29; Mon, 22 Mar 2021 00:25:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 94BBD3858D29 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=charter.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=jvdelisle@charter.net Received: from [192.168.1.9] ([96.41.221.129]) by cmsmtp with ESMTPA id O8OLlDyOL1V8jO8OLlyBUq; Mon, 22 Mar 2021 00:25:59 +0000 Authentication-Results: charter.net; none X-Authority-Analysis: v=2.3 cv=N8md6F1B c=1 sm=1 tr=0 a=07pILqX15KmGv9ZXTMmBNA==:117 a=07pILqX15KmGv9ZXTMmBNA==:17 a=IkcTkHD0fZMA:10 a=sp7UOldkgAGL9SKVsSsA:9 a=QEXdDO2ut3YA:10 Subject: Re: [Patch] Fortran: Fix 'name' bound size [PR99688] To: Tobias Burnus , gcc-patches , fortran , Harald Anlauf References: From: Jerry DeLisle Message-ID: <9879f6b4-4235-38a0-b74e-e1111dc6b82d@charter.net> Date: Sun, 21 Mar 2021 17:25:56 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CMAE-Envelope: MS4wfLE9roxbLOCwk71jyoiK2shrKSxFuQ67hwo6As+AMcJZs2vkoMlR4WzGSS51krv4hkRHzeZVBPrGp8DjpALLKfbSp+JhhL/nij+hxcozcJnOCiY9PtD7 AfocLcKuPF57gHD6z+kDQHnicmvMfR++Eyrcip3YIgy9jHFK0pLn/mOm2d4n0H15WZsAgRbIKTyCTIoo7MhBPPyMsNxAnAicwH7dznQsIiQB8qDWu5+w0Io+ ke1cGPbVrVP9OxfczB2dJA== X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, BODY_8BITS, FREEMAIL_FROM, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: fortran@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Fortran mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2021 00:26:00 -0000 Hi Tobias and others, Reembering some of my own history, we always have used a +1 on 'LENGTH_MAX' items to allow the C null termination on strings or buffers for obvious reasons. Certainly OK for trunk and backports. Regards, Jerry On 3/21/21 9:08 AM, Tobias Burnus wrote: > The gfc_match_select_rank issue showed up in the testsuite > and was found by Martin's asan-bootstrapped GCC. First > analysis by Harald – thanks to both! > > However, I think the other variables I fixed were also > prone to overflows; see below for its usage. > > OK for mainline? Other branches? > > Tobias > > PS: Other pending Fortran patches – please review! > [Patch] Fortran: Fix intrinsic null() handling [PR99651] > [Patch] Fortran: Fix func decl mismatch [PR93660] > > PPS: Usage of 'name' in the patched functions: > > resolve_select_type (gfc_code *code, gfc_namespace *old_ns) >   char name[GFC_MAX_SYMBOL_LEN]; > ... >         sprintf (name, "__tmp_class_%s", c->ts.u.derived->name); > > > select_intrinsic_set_tmp (gfc_typespec *ts) > { >   char name[GFC_MAX_SYMBOL_LEN]; > ... >         sprintf (name, "__tmp_class_%s", ts->u.derived->name); > > > gfc_match_select_type (void) > ... >   char name[GFC_MAX_SYMBOL_LEN]; > ... >   m = gfc_match (" %n => %e", name, &expr2); > > gfc_match_select_rank (void) > ... >   char name[GFC_MAX_SYMBOL_LEN]; > ... >   m = gfc_match (" %n => %e", name, &expr2); >