On Mon, May 6, 2013 at 6:18 PM, Glenn Fowler <[email protected]> wrote: > > dgk and I talked and we both had a different expectation on newof() > if we take dgk's view we may not have to change much except for > the newof() implementation itself which would only 0-out > the sizeof(type)*#instances bytes and not 0-out the extra bytes > > this may capture most usage except for > newof(0,char,n,0) > which would change to > newof(0,char,0,n)
Erm... can we please _not_ change the |newof()|/|oldof()| macros and keep them as they are right now ? IMO it makes more sense to keep them as they are right now (ast-ksh.2013-05-03) and instead walk over all consumers and switch them either over to |oldof()|, manual |memset()| usage or something else. The manual cleanup has IMO less risk and may reveal some interesting "gems" where the algorithm in the consumer should be restructured/rewritten instead of just using |newof()|/|oldof()|. I just came across a case in a loop (!!) where 8 bytes are allocated via |newof()| ... given now |newof()| works (branch, etc. |memset()| of 8 bytes) it's a total overkill to use it at all in such a case (on x86 the CPU caches will "hide" the madness but on platforms like ARM it'll have a serious performance impact... and libast seems to be full of such cases... I wish Linux would be a tool to disable the CPU L2 caches on a per-process level to reveal such inefficientcy issues). ---- 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] http://lists.research.att.com/mailman/listinfo/ast-developers
