regarding dynamic allocation for pointers

[sam_cit@yahoo.co.in]

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]

Re: regarding dynamic allocation for pointers

sam_cit@yahoo.c o.in wrote:

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.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Barry Schwarz]

Re: regarding dynamic allocation for pointers

On 6 Jan 2007 05:08:24 -0800, sam_cit@yahoo.c o.in wrote:

>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]

Re: regarding dynamic allocation for pointers

sam_cit@yahoo.c o.in wrote:

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.

[CBFalconer]

Re: regarding dynamic allocation for pointers

sam_cit@yahoo.c o.in wrote:

>
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)

[Keith Thompson]

Re: regarding dynamic allocation for pointers

sam_cit@yahoo.c o.in writes:

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.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Heathfield]

Re: regarding dynamic allocation for pointers

CBFalconer said:

sam_cit@yahoo.c o.in wrote:

>>
>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.

<coughI 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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: rjh at the above domain, - www.

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

Re: regarding dynamic allocation for pointers

Richard Heathfield wrote:

CBFalconer said:
>

sam_cit@yahoo.c o.in wrote:

>
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.

>
<coughI 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...

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.

....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]

Re: regarding dynamic allocation for pointers

Harald van D?k said:

Richard Heathfield wrote:

>CBFalconer said:
>>

<snip>

>

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.

>
...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>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: rjh at the above domain, - www.

[Ian Collins]

Re: regarding dynamic allocation for pointers

Richard Heathfield wrote:

Harald van D?k said:
>

>>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.
>

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

--
Ian Collins.

[Richard Heathfield]

Re: regarding dynamic allocation for pointers

Ian Collins said:

Richard Heathfield wrote:

>Harald van D?k said:
>>

>>>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.
>>

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

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

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: rjh at the above domain, - www.

[Ian Collins]

Re: regarding dynamic allocation for pointers

Richard Heathfield wrote:

Ian Collins said:
>
>

>>Richard Heathfield wrote:
>>

>>>Harald van D?k said:
>>>
>>>
>>>>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.
>>>

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

>
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.

--
Ian Collins.

[Richard Heathfield]

Re: regarding dynamic allocation for pointers

Ian Collins said:

Richard Heathfield wrote:

>Ian Collins said:
>>
>>

>>>Richard Heathfield wrote:
>>>
>>>>Harald van D?k said:
>>>>
>>>>
>>>>>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.
>>>>
>>>
>>>And his compiler or lint's job a bit harder?

>>
>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?

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
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: rjh at the above domain, - www.

[Richard Heathfield]

Re: regarding dynamic allocation for pointers

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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: rjh at the above domain, - www.

[Ian Collins]

Re: regarding dynamic allocation for pointers

Richard Heathfield wrote:

Ian Collins said:
>
>

>>Richard Heathfield wrote:
>>

>>>Ian Collins said:
>>>>
>>>>And his compiler or lint's job a bit harder?
>>>
>>>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?

>
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.

>

>>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.
>

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

>

>>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.
>

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.