MSobiecki

I'm new in this forum, so hello everybody Smile

Why does delete[] operator for char * allocated and filled using strcpy() require string to be \0 terminated I mean:

[code]
char *test = new char[3];
strcpy(test, "bla");
delete []test; // error
// while
char *test2 = new char[4];
strcpy(test2, "bla");
delete []test2; // is not an error
// and neither is:
char *test3 = new char[4];
delete []test3; // which is not \0 terminated
[/code]

As far as I know delete[] doesn't require any array to be terminated specific way, only strings cause such problems. Why is it like this

[edit] how to use code quotes on this forum Stick out tongue


Re: Visual C++ Language delete[] char* question

Curt Nichols

MSobiecki wrote:

Why does delete[] operator for char * allocated and filled using strcpy() require string to be \0 terminated

delete[] makes no such demand.

Looking at your first three lines of code:

  • how many bytes have you allocated with new[]
  • how many bytes have you copied with strcpy
  • you only allocated 3 bytes; who owns that 4th byte that you copied into
  • if your use of strcpy corrupted heap, where would it likely show up (if not in strcpy)
  • (delete[] is a heap operation)




Re: Visual C++ Language delete[] char* question

vbvan

As Curt said, this is a classic buffer overrun problem (you forget to allocate space for the trailing '\0'). When the heap is corrupted, you cannot expect correct behavior of your program





Re: Visual C++ Language delete[] char* question

MSobiecki

Okay, so I made an error using strcpy due to no allocating byte for \0, but why does it occur in delete[] and not in (or right after) strcpy
Thanks for your answers.




Re: Visual C++ Language delete[] char* question

einaros

MSobiecki wrote:
Okay, so I made an error using strcpy due to no allocating byte for \0, but why does it occur in delete[] and not in (or right after) strcpy
Thanks for your answers.


The debug version of delete has code to check the surrounding padding to see if there has been a heap overflow.

Instead of managing your own memory, and throwing raw char pointers around, I urge you to look to STL's containers, such as string and vector. That really makes C++ life easier.





Re: Visual C++ Language delete[] char* question

Curt Nichols

einaros wrote:
The debug version of delete has code to check the surrounding padding to see if there has been a heap overflow.

einaros brings up a useful point--if you were running a release build you might never see this sort of coding error fail or you might see it fail 10 minutes later in code that appears entirely unrelated. The extra debug check attempts to make the error apparent closer to where it occurs in the code. For example, if you had written 100 bytes off the end of your buffer into some other data structure, you'd rather have it pointed out by delete[] than find a mysterious problem in code that uses the other data structure.





Re: Visual C++ Language delete[] char* question

rtpninja

Curt Nichols wrote:

einaros wrote:
The debug version of delete has code to check the surrounding padding to see if there has been a heap overflow.

einaros brings up a useful point--if you were running a release build you might never see this sort of coding error fail or you might see it fail 10 minutes later in code that appears entirely unrelated. The extra debug check attempts to make the error apparent closer to where it occurs in the code. For example, if you had written 100 bytes off the end of your buffer into some other data structure, you'd rather have it pointed out by delete[] than find a mysterious problem in code that uses the other data structure.

Could not agree more with the previous posters. If your program's in some kind of corrrupted state, you want it to blow up immediately. So a checked version of delete makes a lot of sense. Also, there's almost never a reason these days to deal with raw character data. std:Tongue Tiedtring, std::wstring, CString, and others are there to help.

Just my .02.