[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Markus Schaber <m.schaber_at_codesys.com>
Date: Wed, 24 Apr 2013 08:23:51 +0000

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.

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.schaber@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
Received on 2013-04-24 10:24:33 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.