> That's what I thought, but I thought when you called free() it didn't
> actually touch the data there, just mark it as free for other programs
> to use or something?
You're right; free doesn't touch the data at that memory location. So the
best case would be your data is still accessible. However, you should never
expect this to be the case.
> So.. it's actually pretty impossible for me to free tmp_cp anyway in
> this case isn't it? The function seems to return cp as an integer, so I
> can't free tmp_cp if I need cp pointing, so be able to prepend(?) /dev/
> into the string?
It is possible to free tmp_cp, but it isn't going to give you the intended
effect. If you were doing a "deep copy" (creating a place in memory for cp
and then copying the value of each item from tmp_cp to its respective place
in cp) you should free tmp_cp. However, because you are just telling cp to
point to the same location as tmp_cp you have to remember that that area of
memory is still needed.
Now, the fact that you are returning cp as an integer when it is really a
char* raises a flag with me. I would return the pointer, and then have the
calling function free the memory location (unless that function hands the
memory location off to something else). However, I haven't seen the entire
code path so I don't know the intention and can't comment if this idea fits
into its view.
Self memory managing can be tricky, but if you keep to these guidelines
you'll be better off:
* malloc/new only when you need it (Some OSes single-thread malloc which
cripples MP performance)
* Never assume malloc/new return what you need
* Do whatever you like to that memory location
* free the pointer when you no longer need it
* Never access that memory location again unless you are told to by malloc
Adrian