Hi, Von: Branko Čibej [mailto:br...@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 > initialisations. > >>> > >> 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. Best regards Markus Schaber 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: m.scha...@codesys.com | 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
