![]() | |||||||||||||
Messages in this thread |
On Thu, 9 Jun 2005, Richard B. Johnson wrote: > On Wed, 8 Jun 2005, Nagendra Singh Tomar wrote: > > The user code can't assume anything about any memory allocated > by malloc(). The first time a buffer is allocated, it may be > zero-filled because of the zeroed pages allocated by the kernel > when the new break address is set. After that, all bets are off > because once you free a buffer and allocate another one, it > will probably contain data from malloc()'s previous allocation. > > Even the very first time malloc() returns a pointer, doesn't > guarantee that the memory will all be cleared. This is because > many malloc()s use just-obtained memory (via brk) to do some > house-keeping which may result in some "strange" numbers in > the memory at some places. > > It is extremely bad coding practice to assume a buffer is > zero filled when writing user-mode code. That's why we have > calloc(). My original question was for glibc (as an application) assuming that memory it gets from brk()/MAP_ANON is zero filled, and _not_ for an application calling malloc() assuming that. glibc does assume that brk() memory is zero filled thats why the glibc calloc() implementation does _not_ zero it again in user space (Ulrich conformed this). This is what was disturbing to me as I was trying to disable zero-filling for brk() pages and to my unpleasant surprise few applications like gcc/awk were breaking. Thanx, Tomar -- You have moved the mouse. Windows must be restarted for the changes to take effect. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-06-10 04:00 [from the cache] ©2003-2008 | |||||||||||||