1

Here how i malloc memory

char *convertToPostfix(char **infixExpr)
{
    char *postfixExpr = (char *) malloc(strlen(*infixExpr) * sizeof(char) * 2);
    ...
    return postfixExpr;
}

Here how i use this memory:

char *subexpr = convertToPostfix(infixExpr);
free(subexpr);
while (*subexpr) 
    postfixExpr[i++]=*subexpr++;

Why does this program work normally after free(subexpr); I mean why is it possible to iterate in while after freeing?

And am i doing everything right working in such way, when function returns some memory, which is freed in another context?

Maxim Masiutin
  • 3,991
  • 4
  • 55
  • 72
  • 2
    see http://stackoverflow.com/a/6445794/1025391 (tagged C++ but mostly applies to your case as well) – moooeeeep Mar 12 '12 at 19:48
  • Fix the bug in your code and the mystery will go away. Buggy code will do strange and unpredictable things, no surprise there. – David Schwartz Mar 12 '12 at 19:48

5 Answers5

2

Your program exhibits undefined behaviour. In short anything can happen, including your program appearing to work.

It's quite common that implementations of malloc/free do not return memory blocks to the underlying OS immediately after you call free. This is done for performance reasons. The next call to malloc may well be most efficiently be handled by returning a pointer to the block that you just freed and therefore re-using it. At this point, in your code, there would be two pointers referring to the same block of memory and who knows what would happen next.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
1

DO NOT USE IT! Because of programmers, relied on some behaviour declared as undefined, other programmers should later reproduce other bugs.

http://www.joelonsoftware.com/articles/fog0000000054.html

Windows 95? No problem. Nice new 32 bit API, but it still ran old 16 bit software perfectly. Microsoft obsessed about this, spending a big chunk of change testing every old program they could find with Windows 95. Jon Ross, who wrote the original version of SimCity for Windows 3.x, told me that he accidentally left a bug in SimCity where he read memory that he had just freed. Yep. It worked fine on Windows 3.x, because the memory never went anywhere. Here's the amazing part: On beta versions of Windows 95, SimCity wasn't working in testing. Microsoft tracked down the bug and added specific code to Windows 95 that looks for SimCity. If it finds SimCity running, it runs the memory allocator in a special mode that doesn't free memory right away. That's the kind of obsession with backward compatibility that made people willing to upgrade to Windows 95.

kirilloid
  • 14,011
  • 6
  • 38
  • 52
1

Reading / writing from / to memory that has been freed is undefined behavior. Your program may work today, and crash tomorrow; or wait until the next full moon before crashing.

The reason it appears to work is because the heap manager has not yet allocated that memory to another caller of malloc(). And free() didn't modify the existing contents of the memory, so whatever you'd written to those locations prior to the call to free() is still in there. But relying on this behavior is a recipe for disaster.

Praetorian
  • 106,671
  • 19
  • 240
  • 328
0

This is undefined behavior. It appears to work, but in reality anything can happen.

The reason it appears to work (probably) is that the memory is not cleared when you call free, but rather marked as re-usable by the operating system.

Luchian Grigore
  • 253,575
  • 64
  • 457
  • 625
0

That's clearly undefined behaviour.

Freeing memory doesn't mean zero-ing it. Most of the time, the memory will simply be marked as "available". As you use it right after freeing, it stills there intact. But if for some reason more memory is needed, it will probably get overwritten.

sidyll
  • 57,726
  • 14
  • 108
  • 151