regarding dynamic allocation for pointers

[sam_cit]

Hi Everyone,

I just heard from a friend of mine that there are few c compilers that
give an error when pointers are not initialised to NULL. Is it correct?
and if so, is there any standard for that?

Thanks in advance...

 

[Joe Wright]

Hi Everyone,

I just heard from a friend of mine that there are few c compilers that
give an error when pointers are not initialised to NULL. Is it correct?
and if so, is there any standard for that?

Thanks in advance...

Incorrect. There is no requirement in the Standard that any pointer be
initialized to NULL by the programmer. If the Standard wants a new
pointer to be NULL, the compiler does it. Static pointers at file scope
for example.

 

[CBFalconer]

I just heard from a friend of mine that there are few c compilers
that give an error when pointers are not initialised to NULL. Is
it correct? and if so, is there any standard for that?

See below for standards (C99). Another option is N1124, but that
is not available in text form. There is no reason to initialize
pointers to NULL. There are many reasons to not derefernce
unitialized and invalid pointers, or NULL pointers.

--
Some useful references about C:
<http://www.ungerhu.com/jxh/clc.welcome.txt>
<http://www.eskimo.com/~scs/C-faq/top.html>
<http://benpfaff.org/writings/clc/off-topic.html>
<http://anubis.dkuug.dk/jtc1/sc22/wg14/www/docs/n869/> (C99)
<http://www.dinkumware.com/refxc.html> (C-library}
<http://gcc.gnu.org/onlinedocs/> (GNU docs)
<http://clc-wiki.net> (C-info)

 

[Barry Schwarz]

Hi Everyone,

I just heard from a friend of mine that there are few c compilers that
give an error when pointers are not initialised to NULL. Is it correct?
and if so, is there any standard for that?

Did you really mean error or is it actually just a warning.

Unfortunately, the standard does not prohibit diagnostics for
non-erroneous code. The standard also does not distinguish between
informational messages, warning messages, error messages, etc.
Consequently, in addition to the required diagnostics (e.g.,
constraint violations), the compiler writer is allowed to add any and
as many additional ones as he wants. It becomes a quality of
implementation issue.

The standard does require the compiler to accept a correct program
even if it issued optional diagnostics.

Some compilers use this flexibility intelligently, such as checking
the types of printf arguments against the conversion specifiers and
reporting mismatches. Others, in my opinion, go overboard (as in the
original post) and apparently do so inconsistently (why not flag other
uninitialized objects besides pointers).


Remove del for email

 

[santosh]

Hi Everyone,

I just heard from a friend of mine that there are few c compilers that
give an error when pointers are not initialised to NULL. Is it correct?
and if so, is there any standard for that?

Thanks in advance...

Any self-respecting compiler *shouldn't* emit an error for an
uinitialised pointer. I don't think the standard prohibits issuing a
diagnostic, (which would be more useful than an error), though. However
a compiler is bound to compile a correct translation unit.

 

[Keith Thompson]

I just heard from a friend of mine that there are few c compilers that
give an error when pointers are not initialised to NULL. Is it correct?
and if so, is there any standard for that?

In what context, and what exactly do you mean by "give an error"?

Pointer objects can be initialized to NULL, initialized to some other
value, or uninitialized. I don't think there's any context in which a
compiler is required to issue a diagnostic for an uninitialized or
null pointer. A decent compiler might issue a non-fatal warning on an
attempt to *use* a null or uninitialized pointer.

Show us an example, and we can tell you (a) what a compiler is
required to do, and (b) what a compiler is allowed to do.

 

[Richard Heathfield]

CBFalconer said:

See below for standards (C99). Another option is N1124, but that
is not available in text form. There is no reason to initialize
pointers to NULL.

<cough> I beg to differ. I can see why you might find reasons not to
initialise, but to say there is *no* reason to initialise is a bit strong,
isn't it?

There are many reasons to not derefernce
unitialized and invalid pointers, or NULL pointers.

And that's a great reason for initialising pointers to NULL if you have no
better value for them - so that you can find out whether you can legally
dereference them by inspecting their value.

 

[Guest]

CBFalconer said:


<cough> I beg to differ. I can see why you might find reasons not to
initialise, but to say there is *no* reason to initialise is a bit strong,
isn't it?

Agreed (although I assume this is merely poor choice of wording on
CBFalconer's part), but...

And that's a great reason for initialising pointers to NULL if you have no
better value for them - so that you can find out whether you can legally
dereference them by inspecting their value.

....it's only in rare situations that you'll really need this.
Statically allocated variables are implicitly initialised to zero, for
auto variables it is almost always possible to not use them until
you've set them to a valid (and non-null) value, and it is impossible
to initialise dynamically allocated memory except by use of the
calloc() function, which is not guaranteed to work as one might expect
for pointers in the first place.

Initialising pointers to NULL can occasionally be good style, though.

 

[Richard Heathfield]

Harald van D?k said:

...it's only in rare situations that you'll really need this.
Statically allocated variables are implicitly initialised to zero,

Yes, but for me they are the exception rather than the rule.

for
auto variables it is almost always possible to not use them until
you've set them to a valid (and non-null) value,

Sure, but what's to stop Joe Maintainer from slipping in a deref by mistake,
halfway between declaration and first assignment? I'd rather make his
debugging job a bit easier by giving him a null pointer to detect.

<snip>

 

[Ian Collins]

Harald van D?k said:



Sure, but what's to stop Joe Maintainer from slipping in a deref by mistake,
halfway between declaration and first assignment? I'd rather make his
debugging job a bit easier by giving him a null pointer to detect.

And his compiler or lint's job a bit harder?

 

[Richard Heathfield]

Ian Collins said:

And his compiler or lint's job a bit harder?

Yes. His time is more valuable than that of his compiler.

 

[Ian Collins]

Ian Collins said:



Yes. His time is more valuable than that of his compiler.

Even if he has to compile the code, program his embedded device and
debug the resulting crash some time later when that execution path is
followed?

I thought you advocated compiling with the highest warning level? Even
if that includes a second pass though lint, it's still quicker and safer
to let the tools find the bug at build time.

 

[Richard Heathfield]

Ian Collins said:

Even if he has to compile the code, program his embedded device and
debug the resulting crash some time later when that execution path is
followed?

You are asking me which takes longer: hunting down a deterministic bug that
your compiler probably can't tell you about or hunting down a
non-deterministic bug that your compiler might be able to tell you about.
Neither of us knows the answer to that one. What I can tell you, however,
is that personally I find deterministic bugs much, much, much easier to fix
that non-deterministic bugs, and I frequently need to use compilers which
*don't* tell me about use-before-assignment problems.

I thought you advocated compiling with the highest warning level?

Yes. If you're saying that a compiler should, at its highest warning level,
warn that an indeterminate value is being referenced, then (a) I agree, but
(b) the Standard doesn't mandate it, and (c) not all compilers do it.
Reality trumps idealism.

Even
if that includes a second pass though lint, it's still quicker and safer
to let the tools find the bug at build time.

If they can. But if they can't, suddenly it's not so safe.

Furthermore, I wonder whether you would expect a compiler to diagnose this
code:

#include <stddef.h>

int foo(int **p);

int main(void)
{
int *ptr;
foo(&p);
return 0;
}

If so, then on what grounds? &p does not evaluate p, so its value is not
used at all in this translation unit.

And if not, then how will your automatic bug-catching automatically catch
this bug?

 

[Richard Heathfield]

Correcting some sillies:

Richard Heathfield said:

{
int *ptr;
foo(&p);
foo(&ptr);

return 0;
}

If so, then on what grounds? &p does not evaluate p, so its value is not
used at all in this translation unit.

If so, then on what grounds? &ptr does not evaluate ptr, so its value is not
used at all in this translation unit.

 

[Ian Collins]

Ian Collins said:



You are asking me which takes longer: hunting down a deterministic bug that
your compiler probably can't tell you about or hunting down a
non-deterministic bug that your compiler might be able to tell you about.
Neither of us knows the answer to that one. What I can tell you, however,
is that personally I find deterministic bugs much, much, much easier to fix
that non-deterministic bugs, and I frequently need to use compilers which
*don't* tell me about use-before-assignment problems.

So do I, but I also test the code with lint and test compile with
compilers that do.

Yes. If you're saying that a compiler should, at its highest warning level,
warn that an indeterminate value is being referenced, then (a) I agree, but
(b) the Standard doesn't mandate it, and (c) not all compilers do it.
Reality trumps idealism.

Then use one that does, if not for the production code, at least for
extra validation.

If they can. But if they can't, suddenly it's not so safe.

Furthermore, I wonder whether you would expect a compiler to diagnose this
code:

#include <stddef.h>

int foo(int **p);

int main(void)
{
int *ptr;
foo(&p);
return 0;
}

If so, then on what grounds? &p does not evaluate p, so its value is not
used at all in this translation unit.

No, there's no reason why foo couldn't contain something like

int foo( int** p )
{
*p = malloc( 42 );

return *p != NULL;
}

So there isn't an error to diagnose.

But if and only if foo dereferences p:

int n = **p;

My version of lint does report:

use before set
ptr defined at x.c(8)

 

[Ian Collins]

But if and only if foo dereferences p:

But if and only if foo dereferences p *before it is assigned*:

 

[Richard Heathfield]

Ian Collins said:

Then use one that does, if not for the production code, at least for
extra validation.

A reasonable point, where such a compiler is available. This is not always
the case. Have you never developed C programs in a closed environment? I
have.

No, there's no reason why foo couldn't contain something like

int foo( int** p )
{
*p = malloc( 42 );

return *p != NULL;
}

So there isn't an error to diagnose.
Agreed.


But if and only if foo dereferences p:

int n = **p;

My version of lint does report:

use before set
ptr defined at x.c(8)

But foo is defined in a completely different translation unit, and the
source to either may not even be available when the other is being linted,
so lint can't know this for sure. It is guessing.

 

[Steve Summit]

Indeed, and well put.

...it's only in rare situations that you'll really need this.

Rare?!? Me, I'd say almost all the time.

This may be more poor choices of wording on various people's
parts, or differences in usage of the word "initialize", but...

Statically allocated variables are implicitly initialised to zero,

Which is of course tantamount to initializing them to NULL,
and this is a great idea.

for auto variables it is almost always possible to not use them until
you've set them to a valid (and non-null) value,

"Almost always?" Me, I'd say merely sometimes, and the practice
could still be considered error-prone.

and it is impossible to initialise dynamically allocated memory except
by use of the calloc() function, which is not guaranteed to work as one
might expect for pointers in the first place.

True, which is why one must always explicitly initialize pointers
in dynamically-allocated memory, typically to NULL. (You may
quibble that this isn't strictly "initialization", but then,
neither is what calloc does.)

Initialising pointers to NULL can occasionally be good style, though.

Again, I'd say almost all the time.

I think you, Richard, and I are all in agreement that a
programming style which strives to ensure that all pointer
objects are all either NULL or pointing to valid memory, and
never in the gray, undefined middle, is an excellent idea.
Sometimes the compiler takes care of initializing pointers for
us, and sometimes we have to, but we have to understand all this
if the strategy is to work effectively.

 

[Keith Thompson]

True, which is why one must always explicitly initialize pointers
in dynamically-allocated memory, typically to NULL. (You may
quibble that this isn't strictly "initialization", but then,
neither is what calloc does.)

[...]

Well, the standard says

The calloc function allocates space for an array of nmemb objects,
each of whose size is size. The space is initialized to all bits
zero.

There's no initializer, but apparently the standard considers it to be
initialization anyway.

 

[Ian Collins]

Ian Collins said:



But foo is defined in a completely different translation unit, and the
source to either may not even be available when the other is being linted,
so lint can't know this for sure. It is guessing.

If that were true, my "if and only if" would be wrong. In this case,
lint had access to the definition of foo.