Von: Branko Čibej [mailto:brane_at_wandisco.com]
> >>> I prefer alloc with explicit initialisation unless we know zero is a
> >>> correct initialisation. Adding initialisation to zero makes it
> >>> harder to use a tool like valgrind to identify missing
> >> Ok, but on the other apr_pcalloc() makes code execution stable and
> >> code will crash if not initialized properly instead of accessing
> >> garbage.
> > Maybe we should add our own define for these cases, to have the stable
> behavior of initializing to NULL in released code while still being able
> to disable this for debugging?
> That's a /great/ way of making release builds behave differently from
> debug builds.
Maybe we can always initialize with zero, and find a way to mark it with
VALGRIND_MAKE_MEM_UNDEFINED from memcheck.h during debug builds.
That way, we have the same behaviour during release and debug builds,
and valgrind still knows that the memory is not correctly initialized
at that point.
CODESYS® a trademark of 3S-Smart Software Solutions GmbH
Inspiring Automation Solutions
3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten | Germany
Tel. +49-831-54031-979 | Fax +49-831-54031-50
E-Mail: firstname.lastname@example.org | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com
CODESYS forum: http://forum.codesys.com
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Received on 2013-04-24 10:24:33 CEST