From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from forward500o.mail.yandex.net (forward500o.mail.yandex.net [37.140.190.195]) by sourceware.org (Postfix) with ESMTPS id 71136385AC3D for ; Wed, 23 Feb 2022 08:58:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 71136385AC3D Received: from myt5-96d8dd611b31.qloud-c.yandex.net (myt5-96d8dd611b31.qloud-c.yandex.net [IPv6:2a02:6b8:c12:5a22:0:640:96d8:dd61]) by forward500o.mail.yandex.net (Yandex) with ESMTP id F1539941C41; Wed, 23 Feb 2022 11:58:38 +0300 (MSK) Received: from myt5-aad1beefab42.qloud-c.yandex.net (myt5-aad1beefab42.qloud-c.yandex.net [2a02:6b8:c12:128:0:640:aad1:beef]) by myt5-96d8dd611b31.qloud-c.yandex.net (mxback/Yandex) with ESMTP id JizD9ySUfz-wcdS9KVg; Wed, 23 Feb 2022 11:58:38 +0300 X-Yandex-Fwd: 2 Received: by myt5-aad1beefab42.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id 7gWv6W7xID-wcI0atoJ; Wed, 23 Feb 2022 11:58:38 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) Date: Wed, 23 Feb 2022 11:58:43 +0300 From: lego12239@yandex.ru To: Emile Michel Hobo Cc: gcc@gcc.gnu.org Subject: Re: strcpy and strcat seem to lead to a stack overflow Message-ID: <20220223085843.GA14936@legohost> Reply-To: lego12239@yandex.ru References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, FREEMAIL_REPLYTO_END_DIGIT, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2022 08:58:43 -0000 On Tue, Feb 22, 2022 at 10:01:47PM +0100, Emile Michel Hobo via Gcc wrote: > Dear developers: > > I find it counterintuitive that if I repeatedly reset a variable by using strcpy with an empty string "" to that variable and then us strcat to add characters to that variable that that seems to lead to a stack overflow. > > I would expect strcpy to first free the variable, then malloc, then copy the string value into the variable. I think that would be a better interpretation, because it can keep running for quite some time before it overflows and doesn’t really call it. strcpy() doesn't dynamically allocate memory according to docs. And this great. Otherwise we will have a performance impact. It would be terrible. For example, i allocate some buffer once at program initialization and later do many strcpy() with it. This is a frequent scenario. > I ended up reimplementing the reset function, implementing it with free and malloc myself, but the way strings have been implemented in C is highly counter-intuitive. In general pointers tend to be bug-prone, but here you would expect this not to happen. Implementing string manipulation routines for your needs is ok. Strings in C are very intuitive. You work mostly without allocations and docs specify this. This is great and give the best performance where we need it. Where you don't need it - you make string manipulation routines for yourself. -- Олег Неманов (Oleg Nemanov)