Thread: Creating a dynamic array of char

> I didn't think you were allowed to write to memory unless it was specifically allocated in full.
Well it may be allocated to you elsewhere, or as "extra" for you, or to someone, or to no one.

Just allocate the size of the array to data.size() + 1 and be done with it. Also make sure you save the pointer that comes back from new, which you are not doing in this case. Otherwise you have a memory leak.

To make it compatible with c_str() you could make it const char * :-). But just a thought.

I originally sized the array with size() + 1, I just took it out to see what would happen. The pointer c_str is a member of my class, so it's saved. I don't know why I redeclared it as a char*, an oversight. Thanks for pointing out the need for constness by the way!

> The pointer c_str is a member of my class, so it's saved. I don't know why I redeclared it as a char*, an oversight.
A deadly one at that too

That's why it pays to have a naming scheme for member variables, ie append underscore for private members, or prepend with "m_" or something.

>> Is it that I'm allowed to keep writing to successive addresses until I hit memory that's already allocated?

No, of course not. Accessing even a single byte outside of what you allocated is undefined behavior and incorrect.

I realize that it's "incorrect," but my point was that I wasn't actually given an error message until the string I laid down at that address was over a certain length. Two or three words went past unnoticed, but any more and I got a bad allocation error. I was just surprised because I had expected the program to puke as soon as I accessed one byte past the one I'd allocated.

Just because it didn't puke for you doesn't mean it won't on my machine, etc. That's the nature of undefined behaviour: it's undefined.

>> I realize that it's "incorrect," but my point was that I wasn't actually given an error message until the string I laid down at that address was over a certain length.

Well, typically, you're only going to get an error message if you try to access a memory address outside of the range(s) allowed to your program by the operating system. This is sometimes indirect, of course, as you might corrupt an area within your own stack, say, in effect overwriting the return address of a function, for instance.

Originally Posted by Sebastiani

Well, typically, you're only going to get an error message if you try to access a memory address outside of the range(s) allowed to your program by the operating system. This is sometimes indirect, of course, as you might corrupt an area within your own stack, say, in effect overwriting the return address of a function, for instance.

Yeah, those bugs are always loads of fun to track down...

Originally Posted by Sharke

What's confusing me is that the program works even though I don't specify a size for the array of char

The last time I played Russian Roulette, I didn't die. It was very confusing.

Originally Posted by cpjust

Yeah, those bugs are always loads of fun to track down...

If you mean "easy to track down," then I agree. It's always easy when the stupid thing crashes. The hard problems are when it DOESN'T crash, but gives subtly wrong answers.

EDIT: Okay, I guess I should define what I mean by "easy." The last random crash I dealt with was an assertion trigger (call to assert() failed and crashed the code, only in debug mode, of course). It took about 2 weeks to find the problem. That was borderline easy. The hard problems take months to find.

Originally Posted by brewbuck

If you mean "easy to track down," then I agree. It's always easy when the stupid thing crashes. The hard problems are when it DOESN'T crash, but gives subtly wrong answers.

in my C class we used a compiler that, when I *accidentally* deferenced a misallocated pointer, gave me the "Done!" that it usually does when a program finishes successfully