strcpy and strcat seem to lead to a stack overflow

strcpy and strcat seem to lead to a stack overflow

[Emile Michel Hobo]

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.

Instead, I got "Illegal instruction: 4".

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.

I hope you can fix this. Personally, I’m looking into switching to Ada.

All the best,


Emile M. Hobo


- Au fin! Et encore en plus. -

Re: strcpy and strcat seem to lead to a stack overflow

[Patrick McGehearty]

You may be thinking of string capabilities in some other language.

Selected from the Linux man pages for these glibc functions:

strcpy:
        char *strcpy(char *dest, const char *src);
        The  strcpy()  function  copies the string pointed to by src, 
including
        the terminating null byte ('\0'), to the buffer  pointed to  by  
dest.
        The  strings  may  not overlap, and the destination string dest 
must be
        large enough to receive the copy.  Beware  of  buffer overruns!

strcat:
        char *strcat(char *dest, const char *src);
        The  strcat() function appends the src string to the dest 
string, over‐
        writing the terminating null byte ('\0') at the end of dest,  
and  then
        adds  a  terminating  null  byte.  The strings may not overlap, 
and the
        dest string must have enough space for the  result.   If dest  
is  not
        large  enough, program behavior is unpredictable; buffer 
overruns are a
        favorite avenue for attacking secure programs.

Neither strcpy nor strcat allocate or release buffers.
The programmer is expected to have previously allocated the dest buffer
of sufficient size. It seems likely from the behavior you describe,
in your case, the const src string is allocated on the stack and your
use of strcat with an unallocated dest is overwriting the end of
the src string on each iteration. Ultimately you either run out
of stack space or wipe out some other stack data which causes
unpredictable behavior.

Strings in C are not particularly user friendly.
As to whether they are intuitive, it all depends on what language we
first learn. Many languages invented in the 70s and 80s did not have
strong string handling capabilities. If you learn string handling on
one of those languages first, you come to not expect much and are
pleasantly surprised when encountering a language that does the
support work for you.

Many recommend using strncpy and strncat which require explicit
string lengths in order to remind the programmer to be careful
about buffer sizes and to avoid the risks of unterminated strings.

- patrick


On 2/22/2022 3:01 PM, 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.
>
> Instead, I got "Illegal instruction: 4".
>
> 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.
>
> I hope you can fix this. Personally, I’m looking into switching to Ada.
>
> All the best,
>
>
> Emile M. Hobo
>
>
> - Au fin! Et encore en plus. -
>

Re: strcpy and strcat seem to lead to a stack overflow

[lego12239]

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)

Re: strcpy and strcat seem to lead to a stack overflow

[Jonathan Wakely]

On Tue, 22 Feb 2022 at 21:02, Emile Michel Hobo wrote:
> I hope you can fix this.


There is nothing to fix, strcpy and strcat work exactly as required by
the C standard, and that isn't going to change. In any case, it's
off-topic on this mailing list because those functions are defined in
the C standard and provided by the C library on your OS, not by GCC.
This list is for discussing the development of GCC itself.

> Personally, I’m looking into switching to Ada.

GCC has a very capable Ada compiler, so maybe you will be happy using
that instead of C.