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

RE: 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: Bert Huijben <bert_at_qqmail.nl>
Date: Wed, 24 Apr 2013 13:23:04 +0200

> -----Original Message-----
> From: MARTIN PHILIP [mailto:codematters_at_ntlworld.com] On Behalf Of
> Philip Martin
> Sent: woensdag 24 april 2013 12:44
> To: Bert Huijben
> Cc: 'Branko ibej'; dev_at_subversion.apache.org
> Subject: Re: 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
>
> "Bert Huijben" <bert_at_qqmail.nl> writes:
>
> > Well, explicitly not initializing variables is another way of adding
> > undefined behavior.
>
> You are suggesting that all heap variables be explicitly initialised to
> zero before being initialised to the correct values. We don't do that
> for stack variables, why is it so important to do it for heap variables?

How long do stack variables live?
How many functions do use them directly?
How much warnings does a common compiler give on using uninitialized
variables on the stack?

How long do head variables live?
How many functions do use them directly?
How much warnings does a common compiler give on using uninitialized
variables on the heap?

Especially because that last number is 0 and the number for stack variable
diagnosis is usually higher (and at least one of our buildbots continuously
uses compiler generated checks for unset stack variables), I think
initializing on the heap doesn't cost much but makes behavior more stable.
Really large blobs might be an exception, but in other cases initializing to
0 makes sense.

And I'd rather be a tiny bit more safe than sorry in these cases.

        Bert
Received on 2013-04-24 13:24:10 CEST

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