Initialising Variables

[Jorgen Grahn]

One advantage of C99 is the ability to mix variable declarations and
code, so this debate becomes moot.

No, it doesn't.

int i;
if(something) {
i = f1();
}
else {
i = f2();
}
// i is now guaranteed to have a good value
use(i);

OK, you can use ?: here, or invent a f1_or_f2(someting) helper,
but you will encounter this problem.

BR,
/Jörgen

 

[Chris Dollin]

No, it doesn't.

int i;
if(something) {
i = f1();
}
else {
i = f2();
}
// i is now guaranteed to have a good value
use(i);

OK, you can use ?: here, or invent a f1_or_f2(someting) helper,
Exactly.

but you will encounter this problem.

Once in a blue moon in C99 you will find something where there is no nice
way to initialise a variable to its appropriate initial value and
instead have to separate its declaration and an initialising assignment,
yes.

[Reiner Knizia rules!]

 

[Jorgen Grahn]

....
Initialising variables to a safe or default value is mainly a feel-good
thing.

Depends. For me, seeing it in existing code is a warning sign, and I tend to
remove the initialization -- after analysing the code.

....

If your code is correct, then dummy initialisations rarely have a
useful effect. If your code is wrong, then the default values, (often
zero), are as likely to lead to wrong results than an arbitrary value.

Yes, in cases where there is no /useful/ default.

I treat the two forms as a kind of documentation. In my head,
it works like this:

void f(void) {
int i = 0;
...
}

- this value is actually used in the code below, or,
- the code was too complex to analyze for the writer; he wasn't sure
all code paths change the value of i before using the value,
/and/ 0 is a harmless default (maybe it flags an error later on)

void f(void) {
int i;
...
}

- there was no reasonable way to rework this so that i could be initiated
with a meaningful value at its definition, and,
- the writer is confident that all code paths initialize i before using it.

/Jorgen

 

[Christopher Layne]

I am not denying the existence of hard-to-find bugs. I am, however, saying
that bugs are easier to find if they stand still.

So why not make them stand still when you *need them to stand still* rather
than doing it by default?

 

[Richard Heathfield]

Christopher Layne said:

So why not make them stand still when you *need them to stand still*
rather than doing it by default?

Because I always need them to stand still. If my program is littered
with indeterminacies, tracking down the particular one that is making
my life difficult is much harder.

 

[Christopher Layne]

Christopher Layne said:


Because I always need them to stand still. If my program is littered
with indeterminacies, tracking down the particular one that is making
my life difficult is much harder.

Okay, so do you do this?

int func(void)
{
type *t = NULL;
/* where t is not going to be the head of a linked list */

/* 30 lines of other stuff not involving t */

t = get_new_t_from_pool();
/* stuff with t */

return 0;
}

Where you *know* t does not have a chance of even being used before
alloc/init/whatever?

 

[Richard Heathfield]

Christopher Layne said:

Okay, so do you do this?

int func(void)
{
type *t = NULL;
/* where t is not going to be the head of a linked list */

/* 30 lines of other stuff not involving t */

t = get_new_t_from_pool();
/* stuff with t */

return 0;
}

Where you *know* t does not have a chance of even being used before
alloc/init/whatever?

Yes, because even though I *know* t doesn't stand a snowball's chance in
Arizona of being used before the call, I also *know* that what I *know*
very often turns out to be based on information which changes between
the time I write the code and the time it gets maintained.

Indeed, why does code need to be maintained? Probably it's either
because the code was broken - in which case fixing it may well involve
further, potentially risky, tinkering t before that call - or because
the requirements have changed, in which case what I *knew* to be true
before may no longer be true.

 

[Ian Collins]

Richard Heathfield wrote:




Okay, so do you do this?

int func(void)
{
type *t = NULL;
/* where t is not going to be the head of a linked list */

/* 30 lines of other stuff not involving t */

Factor out some or all of the 30 lines, they are making the function too
big.