8

In section 6.3 of the book "Inside the C++ Object Model", Temporary Objects (page 230):

The actual results are implementation dependent based on how aggressive the underlying delete operator is in actually freeing the memory addressed. Some implementations, while marking the memory as free, do not actually alter it in any way. Until the memory is claimed by something else, it can be used as if it had not been deleted. While obviously not an exemplary approach to software engineering, this idiom of accessing memory after it has been freed is not uncommon. Many implementations of malloc(), in fact, provide a special invocation malloc(0); to guarantee just this behavior.

According to the above, malloc(0) seems to be related to accessing memory which has already been freed (but the content of which has not been changed).

My question is how malloc(0) can guarantee this behavior?

johnsyweb
  • 136,902
  • 23
  • 188
  • 247
user571470
  • 394
  • 4
  • 14

3 Answers3

2

EDIT: I did not notice that "inside the C++ object model" was a reference and not merely part of the question title.

As Dietmar Kuhl says, it looks like a kludge and you shouldn't rely on such an extension even it appears on your platform.

"Most platforms" do include some kind of malloc debugging facility to help programmers find code that accesses memory already passed to free. This can involve performing memory management less lazily or overwriting with special byte pattern. It sounds like that text is describing malloc(0) as a means of disabling such a facility. On Mac OS X I recall there is an environment variable (something like MALLOC_DEBUG) which controls this. What the facility does and how it is enabled will vary a lot between platforms. Overriding malloc(0) is neither common nor a good interface.

EDIT: I found it in Inside the C++ object model by Stanley Lippman, 1996. Not an authoritative source. That entire page appears to be devoted to discussing differences between standard and "pre-standard" platform implementations, although 1996 was also before the first standard was finished. Be aware that was a long, long time ago in computer years and unless you're bringing a specific app back from the dead, such information will be totally irrelevant. Lippman apparently released a new book on C++11, which includes an updated object model with multithreading support. (Although I don't know whether he or that book is any good.)

Potatoswatter
  • 134,909
  • 25
  • 265
  • 421
  • The chapter and page numbers OP gave do match this paperback I have: [Inside The C++ Object Model](http://www.amazon.co.uk/dp/0201834545/). – DCoder Dec 25 '12 at 06:34
  • @DCoder Heh, Google found it for me :) . – Potatoswatter Dec 25 '12 at 06:40
  • To be fair, the OP *did* specify that book title in the title of his post :) – DCoder Dec 25 '12 at 06:42
  • @DCoder Oh, the lack of punctuation/formatting completely confused me. Apparently the internet has finally blinded me to the subtlety of capitalization. – Potatoswatter Dec 25 '12 at 06:44
  • Also: Lippman is very very good. His C++ Primer is one of the most outstanding books for learning C++. – DWright Dec 25 '12 at 06:45
  • @DWright May be, but wouldn't know it from the pages after that link, which are clearly written but meander through various platform differences and ambiguities that I wonder would ever have been relevant to someone trying to make sense of C++ as a portable language. – Potatoswatter Dec 25 '12 at 06:48
  • 1
    That book is meant as a deep dive into the guts of C++ implementations (at the time). Also a super valuable book (at the time). See under the Classics section at http://stackoverflow.com/questions/388242/the-definitive-c-book-guide-and-list. – DWright Dec 25 '12 at 06:50
  • @Potatoswatter: The original "Inside the C++ Object Model" was a great book and many of the points still hold although implementation details clearly have moved on dramatically since then. Also, Stan Lippman is one of the early C++ celebraties and he has written several very good books. Thanks for pointing out that there is an updated version: This is certainly a book I'll get! – Dietmar Kühl Dec 25 '12 at 21:52
  • @DietmarKühl: Can you (and the post owner) please point out the name of the new version of that book? I couldn't find it. – user571470 Dec 26 '12 at 15:55
  • @user571470 It's an updated edition of his *Primer*, not this more technical book. – Potatoswatter Dec 26 '12 at 15:58
1

From the quote it seems that there are implementations of malloc() which use malloc(0) as some sort of switch to indicate that future calls to malloc() allocate memory in a way that free() (and probably realloc(p, 0)) won't change the content of the allocate memory when marking it as unused. This is, clearly, a standard conforming extension which you'd better not rely on.

Dietmar Kühl
  • 150,225
  • 13
  • 225
  • 380
  • To be more precise, how can `malloc(0)` be used to indicate that the future allocated memory can be freed without changing the content? – user571470 Dec 25 '12 at 04:08
  • Simple: It sets an internal variable (e.g., `static` in the translation unit where `malloc()` is defined) to allocate more memory: The memory blocks handed out tend to be prefixed by some size information. When returning the block, it could be added to a linked list whose pointers are stored in the first few bytes of the memory block. If these bytes had been available to the user they would change. Allocating slightly more memory and leaving the space open for the pointers would avoid that the content is accidentally changed. – Dietmar Kühl Dec 25 '12 at 04:25
0

From the practical standpoint malloc can't even grant some space to be really allocated.

The most effective way to see how malloc operates is to think about it as a request for the kernel, the kernel can say "ok" or "no", but if the kernel says "ok" you simply can't be sure if it really allocates memory for you or it's just saying "ok" to make you happy.

It's kind of an overbooking about the memory pages, it's a common problem under linux for example, usually the linux kernel is highly permissive on malloc requests but it can happen that you run out of memory even if your malloc request returns a positive result.

If you want a name for a topic search for "Linux memory overcommit" and you will get a general idea about how malloc works under Linux, similar concepts applies on other platforms meaning that you will never get a consistent and cross-platform compatible behaviour from malloc and everything basically depends from the kernel.

user1824407
  • 4,401
  • 4
  • 15
  • 20
  • `malloc` is not a system call on most systems (Linux included), so the kernel does not get involved. More pages can be allocated via `sbrk` and `mmap`. However, overcommit is a real problem in memory allocation. – Yann Ramin Dec 25 '12 at 03:47
  • @YannRamin the kernel manages the memory and the memory pages, I'm not saying that malloc is a system call ( in practice it is ... ) but if the kernel doesn't manage memory request i can't think about something that actually does it. – user1824407 Dec 25 '12 at 03:49
  • I am actually asking how malloc(0) can guarantee the behavior described in the quote. – user571470 Dec 25 '12 at 04:02
  • @user571470 the answer is basically the same, the phrase from the quoted text starts with "Many implementations of" and the word "many" is quite generic. Document yourself about the platform-specific behaviour of malloc for the OS that you are targeting, this is the best advice that you can get. – user1824407 Dec 25 '12 at 04:05