> -----Original Message-----
> From: Markus Schaber [mailto:m.schaber_at_codesys.com]
> Sent: woensdag 24 april 2013 10:24
> To: dev_at_subversion.apache.org
> Subject: AW: svn commit: r1470936 - in /subversion/trunk/subversion:
> include/svn_io.h libsvn_subr/stream.c libsvn_wc/adm_ops.c
> libsvn_wc/update_editor.c
>
> Hi,
>
> 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
> > 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.
And this is an even better suggestion: just initialize to 0, but learn valgrind to handle this...
Bert
Received on 2013-04-24 10:55:11 CEST