regarding dynamic allocation for pointers

Discussion in 'C Programming' started by sam_cit@yahoo.co.in, Jan 6, 2007.

  1. Guest

    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...
    , Jan 6, 2007
    #1
    1. Advertising

  2. Joe Wright Guest

    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 ---
    Joe Wright, Jan 6, 2007
    #2
    1. Advertising

  3. CBFalconer Guest

    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)
    CBFalconer, Jan 6, 2007
    #3
  4. On 6 Jan 2007 05:08:24 -0800, 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
    Barry Schwarz, Jan 6, 2007
    #4
  5. santosh Guest

    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.
    santosh, Jan 6, 2007
    #5
  6. 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_Keith) <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.
    Keith Thompson, Jan 6, 2007
    #6
  7. CBFalconer said:

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


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

    --
    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, Jan 6, 2007
    #7
  8. Richard Heathfield wrote:
    > CBFalconer said:
    >
    > > 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.

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

    > > 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.
    =?utf-8?B?SGFyYWxkIHZhbiBExLNr?=, Jan 6, 2007
    #8
  9. 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.
    Richard Heathfield, Jan 7, 2007
    #9
  10. Ian Collins Guest

    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.
    Ian Collins, Jan 7, 2007
    #10
  11. 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.
    Richard Heathfield, Jan 7, 2007
    #11
  12. Ian Collins Guest

    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.
    Ian Collins, Jan 7, 2007
    #12
  13. 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, Jan 7, 2007
    #13
  14. 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.
    Richard Heathfield, Jan 7, 2007
    #14
  15. Ian Collins Guest

    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.
    Ian Collins, Jan 7, 2007
    #15
  16. Ian Collins Guest

    Ian Collins wrote:
    >
    > But if and only if foo dereferences p:


    But if and only if foo dereferences p *before it is assigned*:
    >
    > int n = **p;
    >
    > My version of lint does report:
    >
    > use before set
    > ptr defined at x.c(8)
    >


    --
    Ian Collins.
    Ian Collins, Jan 7, 2007
    #16
  17. Ian Collins said:
    > Richard Heathfield wrote:
    >> Ian Collins said:


    <snip>

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


    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.

    <snip>

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


    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.

    --
    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, Jan 7, 2007
    #17
  18. Steve Summit Guest

    Richard Heathfield wrote:
    >> 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.


    Indeed, and well put.

    Harald van D?k wrote:
    > ...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.
    --
    Steve Summit
    Steve Summit, Jan 7, 2007
    #18
  19. (Steve Summit) writes:
    [...]
    > 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.

    --
    Keith Thompson (The_Other_Keith) <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.
    Keith Thompson, Jan 8, 2007
    #19
  20. Ian Collins Guest

    Richard Heathfield wrote:
    > Ian Collins said:
    >
    >>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.
    >

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

    --
    Ian Collins.
    Ian Collins, Jan 9, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    5
    Views:
    370
    -berlin.de
    Dec 24, 2004
  2. srini

    Dynamic mem allocation for pointers

    srini, Dec 14, 2005, in forum: C Programming
    Replies:
    4
    Views:
    355
    Barry Schwarz
    Dec 18, 2005
  3. Ken
    Replies:
    24
    Views:
    3,865
    Ben Bacarisse
    Nov 30, 2006
  4. chris
    Replies:
    6
    Views:
    989
    chris
    Oct 28, 2005
  5. saurabh29789

    Regarding Dynamic Memory Allocation

    saurabh29789, Feb 10, 2009, in forum: C Programming
    Replies:
    1
    Views:
    257
    jameskuyper
    Feb 10, 2009
Loading...

Share This Page