I called TlsFree after storing something in the Thread Local Storage and when I call TlsGetValue(...) it returns the object! Why is this?
I called TlsFree after storing something in the Thread Local Storage and when I call TlsGetValue(...) it returns the object! Why is this?
Deallocating a resource doesn't necessarily destroy the "bits" of that resource. So it still might appear to be there, even though it isn't. Accessing it is still wrong.
As an analogy, imagine that you've been banned from campus. That doesn't mean you can't go on campus, it just means you'll get in trouble if you get caught
The real question of the day is why are you trying to use a freed buffer? Or were you just curious.
It *is* freed. The values of the bits are still there, however. If you want, you could clear the buffer to zero (or some other value indicating "been freed"), BEFORE freeing it.
Accessing freed storage is a common error, which often goes undetected for exactly this reason. Some runtimes will mark storage with special byte values before freeing it, when operating in debug mode, to try to catch these errors.
As explained above, the free function doesn't actually remove the data in the entry, it just says "this index can be used again".
Something like this seems like a good idea:
--Code:void myTlsFree(long &index) { TlsSetValue(index, 0); TlsFree(index); index = 0; }
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
There were many programs that broke on the transition to Win95 because it was far less forgiving about accessing freed memory than Win 3.x.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law