how do i concatenate a string with an integer?

Started by
12 comments, last by Zahlman 17 years, 5 months ago
Quote:Original post by rip-off
Quote:
rip-off's posts will result in memory corruption.


I'm sorry, but how? [smile]

Granted the function requires that the buffer has enough space to handle the extra characters being appended (which I should have checked [embarrass]), but once that has been met how would there be memory corruption?


That would be the problem that's alluded to.

Note that 'char* buffer = /* some C string */' doesn't suggest anything about checking buffer size. The point is, you *have* to "own" memory following the string that is big enough to hold the text representation of the number, and it *has* to not be in use for something else already.
Advertisement
Quote:Original post by Zahlman
Quote:Original post by rip-off
Quote:
rip-off's posts will result in memory corruption.


I'm sorry, but how? [smile]

Granted the function requires that the buffer has enough space to handle the extra characters being appended (which I should have checked [embarrass]), but once that has been met how would there be memory corruption?


That would be the problem that's alluded to.

Note that 'char* buffer = /* some C string */' doesn't suggest anything about checking buffer size. The point is, you *have* to "own" memory following the string that is big enough to hold the text representation of the number, and it *has* to not be in use for something else already.


Oh, ok, I though NotAYakk was implying that it currently ( even with most of the size 100 example buffer empty ) was causing memory corruption, not that it had the possibility of memory corruption if misused( which I was aware of ), if you know what I mean.

I should have thought more of your signature, really.


How will your posts cause memory corruption?

They will cause memory corruption in two ways. Both in the particular and in the abstract.

char *buffer = /*some c string */;sprintf(buffer + strlen(buffer),"%d",i);


No length checking is done above -- so in the particular, you have memory corruption above. There are c strings that will cause the above chunk of code execute undefined behaviour.

...

In the abstract, if you don't keep the eye on the ball -- keep track of the length of every c string you append data to -- you will cause memory corruption in a project.

You'll even usually get lucky -- memory will be allocated with room between one chunk of memory and the next, and most of the time you will have enough room. Quite often because "common memory corruption" gets weeded out as the application crashes.

But the more you work with blocks of memory without always keeping track of their length, the more memory corruption you will have.

So never ever ever make any string longer if you don't know how long it is. Always check to see if the buffer you are modifying will have enough room to store the string you want to store there.

I find the best way to deal with never and always commandments is to touch your data only with functions (ADT), and don't manipulate the data directly.

Hence the Buffer struct, and the functions I provided that start off manipulating them.
Quote:Original post by NotAYakk
How will your posts cause memory corruption?


Aww, I was expecting the answer "by introducing the risk that the OP would remember a dangerous way of doing things" ('remember' being the operative word). :)

This topic is closed to new replies.

Advertisement