public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: lego12239@yandex.ru
To: Emile Michel Hobo <e.m.hobo@hotmail.nl>
Cc: gcc@gcc.gnu.org
Subject: Re: strcpy and strcat seem to lead to a stack overflow
Date: Wed, 23 Feb 2022 11:58:43 +0300	[thread overview]
Message-ID: <20220223085843.GA14936@legohost> (raw)
In-Reply-To: <AM6P194MB0263B192623F4BBFD53A4C10AE3B9@AM6P194MB0263.EURP194.PROD.OUTLOOK.COM>

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)

  parent reply	other threads:[~2022-02-23  8:58 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-22 21:01 Emile Michel Hobo
2022-02-23  0:47 ` Patrick McGehearty
2022-02-23  8:58 ` lego12239 [this message]
2022-02-23  9:47 ` Jonathan Wakely

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220223085843.GA14936@legohost \
    --to=lego12239@yandex.ru \
    --cc=e.m.hobo@hotmail.nl \
    --cc=gcc@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).