glib dependency for the X Server

[Greg Stark]

Carsten Haitzler (The Rasterman) <raster at rasterman.com> writes:

> it's not always free. in theory it should be free when its a fresh page from
> the OS as the kernel will have zeroed it out for security reasons anyway (and
> i'd hope libc is smart enough to know this - if it's not - then its the price
> of a page re-use). secondly i calloc damn near everything myself because

Except that most calloc calls won't actually be coming memory from fresh
allocations. Mostly they'll be returning memory freed earlier. (Unless you're
allocating large blocks (like 32k+))

I actually doubt any malloc library goes to much effort to consistly skip
initializing the memory returned by calloc. Skimming the glibc source it makes
some effort but only manages to cover the case where the memory being returned
came from a *fresh* allocation. Ie, if you call calloc for 1 byte and there
are no free blocks it will sbrk or mmap to get a block of more memory and skip
initializing your 1 byte. But then subsequent calls will return memory from
that same pool and won't manage to skip the initialization.

> 1. structs of mine in a "safe known state" are all 0.
> 2. it has saved me from countless 100's of bugs by always having a known
> starting state (my pointers are 0 - my values are 0 - everything in a known
> state i always check for and skip/abort any more work on)

For maximum pedantry you realize there's no guarantee in ANSI that NULL is
represented by the all-zero bitpattern? I'm not even sure there is for integer
0 for that matter.

I tend to think of the routine unnecessary use of calloc as *hiding* as many
bugs as it saves you from. I've seen plenty of programs that happen to work
despite missing some key initialization precisely because either calloc or a
programmer trying to silence a compiler warning had already stuffed some
plausible values in (such as 0) only to fail unpredictably much later.

-- 
greg