<ast.h> has oldof() which uses malloc() instead of calloc() newof() is for a common paradigm of allocating a base struct immediately followed by a variable extendable region where the base struct must be initialized and the extendable region not necessarily initialized
some newof() calls in ast could be changed to oldof() but changing newof() to use malloc() instead of calloc() would certainly invite undefined behavior in code that expects an initialized base struct On Wed, 16 May 2012 13:11:34 +0200 Roland Mainz wrote: > Hi! > ---- > While debugging something else I found the following definition of |newof()|: > -- snip -- > #define newof(p,t,n,x) > ((p)?(t*)realloc((char*)(p),sizeof(t)*(n)+(x)):(t*)calloc(1,sizeof(t)*(n)+(x))) > -- snip -- > The definition puzzels me a bit because it looks like a chimera: If > |p| is |NULL| it will return memory which is filled with |0| while if > |p| is not |NULL| it will use |realloc()|, but without filling memory > was added (assuming the |realloc()| grows the memory area) with |0| > ... > ... which leads to the question: Should |newof()| really use > |calloc()| (or even initalise memory with '\0') ? Filling the memory > with '\0' has a few disadvantges, including that it is time-consuming > and that it generates page hits [1] and consumes cache even if the > memory isn't touched for some time (after digging through the results > of some cache profiling utilities it looks like libast-based > applications suffer a lot from memory fills with '\0' immediately > followed by normal writes into the same location (which makes the > '\0'-fill redundant; for ksh93 almost 1.4% of the startup time are > consumed that way)). > Based on these results my proposal would be: If noone objects I'd > prefer to change the macro to use |malloc()| instead of |calloc()| to > make it a bit more efficient. > [1]=The page hits are usually unavoidable... my issue is that the page > hit (and therefore related actions by the kernels VM subsystem, e.g. > page mapping) happens at that point while the "real" usage happens > _much_ later. Same (with likely much more performance impact) applies > to the caches. > ---- > Bye, > Roland > -- > __ . . __ > (o.\ \/ /.o) [email protected] > \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer > /O /==\ O\ TEL +49 641 3992797 > (;O/ \/ \O;) > _______________________________________________ > ast-developers mailing list > [email protected] > https://mailman.research.att.com/mailman/listinfo/ast-developers _______________________________________________ ast-developers mailing list [email protected] https://mailman.research.att.com/mailman/listinfo/ast-developers
