glib dependency for the X Server

[Carsten Haitzler (The Rasterman)]

On 06 Apr 2006 01:10:52 -0400 Greg Stark <gsstark at mit.edu> babbled:

> 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.

yup - it's possible - but frankly - the other size of things would be malloc()
then memset() the thing to 0 anyway as i want my members set to an initial
"sane" value that i can depend on. this way i never forget to set a value to a
"sane" one as it always comes that way :) only in special cases do i skip this
and specially malloc then init certain members or for vast memory wads (eg
pixel data).

> > 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

i know :) but i have an autoconf check for that actually in configure - and
frankly.. the code refuses to compile then :)

> represented by the all-zero bitpattern? I'm not even sure there is for integer
> 0 for that matter.

i know :) see above.

> 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.

yeah- BUT for me - i tend to DESIGN my code where "0" is a plausible and
DESIREABLE "default starting" value OR an invalid value (eg a NULL pointer -
see above - i know about its caveats that it may NOT be 0)  so i wont
de-reference a pointer if its null (ie the object hasn't been attached yet for
example or its in a "created but not initialised state - eg an image object
would have a struct for its control info and properties but may not alloc the
pixel data until needed - i.e. i may load an image file header and get its
width, height, colorspace info etc., but not decode pixel data until demanded,
saving a fair bit of work when you just want to create objects that don't become
visible until later - or never)

> -- 
> greg
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com
裸好多
Tokyo, Japan (東京 日本)