Variable declaration and initialisation

[Eric Sosman]

Emmanuel Delahaye wrote On 01/17/06 16:09,:

Eric Sosman a écrit :


I understand your point, but I prefer to use a different coding
technique based on the reduction of the scope of functions and objects:

void f(void)
{
{
char *p = malloc(strlen(string1) + 1);
if (p == NULL)
die();
strcpy (p, string1);
}

{
char *q = malloc(strlen(string2) + 1);

if (q == NULL)
die();
strcpy (q, string2);
}
<...>

and magically, the bug did'nt happen at all.

And if you need to work with both p and q in the
same scope ...?

For example, if die() is "return an indication of
failure, e.g., -1 or NULL" (and the return type of f()
is suitably adjusted), the die() after the failure to
allocate memory for q would presumably want to free(p)
so as not to leak memory. What then?

We could go on making up examples and counter-examples
pretty much indefinitely, especially since neither point
of view is entirely unreasonable. (Mine is MORE reasonable
than yours, OF COURSE, harrumph, harrumph, but that's
another matter. ;-) However, the O.P.'s question was

2) Should all variabled be initiailised immediately
after declaration?

... and I think you'll agree that the word "all" calls
for the answer "No" from both the Usually-Initialize and
the Usually-Don't crowd.

(Strangest language I ever saw had an interesting way
of catching attempts to use uninitialized variables. They
were always accessed via indirection through a sort of
symbol table, and the compiler deliberately set the low-
order bits of the table's pointers so they'd be mis-aligned.
On a write, the code zeroed the pointer's low-order bit,
but on a read it simply used what the table contained.
Result: Try to read a variable before a write has repaired
its pointer, and you get a hardware trap. The run-time
would print a diagnostic message giving the name of the
variable and the line that performed the bad reference, and
then would initialize the variable to 1 and resume. Why 1?
Just in case the program was about to divide by it ...)

 

[Mark B]

Eric Sosman a écrit :
I understand your point, but I prefer to use a different coding technique
based on the reduction of the scope of functions and objects:

void f(void)
{
{
char *p = malloc(strlen(string1) + 1);
if (p == NULL)
die();
strcpy (p, string1);
}

{
char *q = malloc(strlen(string2) + 1);

if (q == NULL)
die();
strcpy (q, string2);
}
<...>

and magically, the bug did'nt happen at all.

Your code is most definately not the equivalent of Eric's.
His is meant to perform further work with the dynamically
allocated memory segments and I'm sure they'll later be
freed in the section left out (specified by the elipses).
Yours created 2 memory leaks!

 

[Emmanuel Delahaye]

Mark B a écrit :

Your code is most definately not the equivalent of Eric's.
His is meant to perform further work with the dynamically
allocated memory segments and I'm sure they'll later be
freed in the section left out (specified by the elipses).
Yours created 2 memory leaks!

Ahem... say "the ellipses was misplaced", huh...