why the value is still available

Discussion in 'C Programming' started by xdevel, Oct 4, 2006.

  1. xdevel

    xdevel Guest

    Hi,
    in a function if I have

    int * retArray()
    {
    int a[3] = {102,222,355};

    printf("%p ", a);

    return a;
    }

    and then in main()

    int *p = retArray();
    p++;
    printf(" \n%p\n %d", p, *p);

    the compiler warning me: ../c_test.c: In function 'retArray':
    .../c_test.c:24: warning: function returns address of local variable
    and for this why the array variables values are still there ?

    I've studied that when the function end the local variables loosing
    their values as they
    are distroyed and so If I want that they are not destroyed I should use
    the static word before them...
     
    xdevel, Oct 4, 2006
    #1
    1. Advertisements

  2. It is undefined behavior to try to access that pointer, meaning
    things could "work",not work, work for a period of time, etc.
    You are returning a pointer to a local element of your array.
    This array has auto storage, it goes out of scope when the function
    ends.
    You could have the caller pass in a pointer to storage where your
    function can fiddle with.
     
    =?ISO-8859-1?Q?=22Nils_O=2E_Sel=E5sdal=22?=, Oct 4, 2006
    #2
    1. Advertisements

  3. Don't use static.

    #include <stdio.h>
    #include <stdlib.h>

    void doArray(int *a, size_t c)
    {
    size_t i;

    for (i = 0; i < c; i++) printf("%p ", (void *)&a);
    printf("\n");

    return;
    }

    int main(void)
    {
    int a[3] = { 102, 222, 355 };

    doArray(a, 3);

    return 0;
    }}
     
    Christopher Layne, Oct 4, 2006
    #3
  4. xdevel

    xdevel Guest

    Christopher Layne ha scritto:


    yes but my question was relative to the situation of an array creation
    inside a funcion :)
     
    xdevel, Oct 4, 2006
    #4
  5. xdevel said:
    printf("%p ", (void *)a);
    Don't do that. The array stops existing when the function returns, so its
    address isn't much use to anyone.
    The program's behaviour is undefined, because the value of p is
    indeterminate and yet you've tried not only to use it but even to
    dereference it.
    One possible outcome of undefined behaviour (although by no means the only
    one) is that, on this particular occasion, the program behaves in the way
    you observed, and has no unfortunate side-effects such as randomly
    corrupting a single bit in your system directory.
     
    Richard Heathfield, Oct 4, 2006
    #5
  6. xdevel

    xdevel Guest

    Richard Heathfield ha scritto:
    thanks you are always clear and precise in your answers.
     
    xdevel, Oct 4, 2006
    #6
  7. xdevel

    Ark Guest

    Christopher Layne wrote:
    There is a school of thought that says automatic (basically, on-stack)
    arrays are evil. Reason: as a mere mortal, I'm bound to make an
    off-by-one mistake sooner or later, and do something unpredictable, like
    corrupt the return address of my caller. That's pretty darn hard to debug.
    For the most part, I sorta bought into this (arrays are static or
    dynamically allocated, which normally comes at a price of access
    efficiency).
    Is it overly paranoid? Any comments from safety- or mission- critical or
    related fields?
    Thank you,
    -Ark
     
    Ark, Oct 5, 2006
    #7
  8. I wouldn't write sub-optimal code because of "could happen"'s. The reason I
    said don't use static has to do with re-entrancy. Not that using static
    automatically makes a function non-reentrance *in-use* - just that in his
    particular example that was what he was shooting for.

    Also, off-by-one errors are going to screw you if an array is auto or not.
     
    Christopher Layne, Oct 5, 2006
    #8
  9. xdevel

    Ark Guest

    That's the notion of "defensive programming". People do it all the time.
    The reason I
    True. But if I corrupt data only, I have a better chance of successful
    debugging.

    - Ark
     
    Ark, Oct 5, 2006
    #9
  10. I tend to categorize defensive programming as being defensive against
    internals (input lengths, maybe-cases, etc) and vague assumptions in code
    (proper parenthesizing, not making ridiculous use of operator precedence that
    not all may remember) rather than defending against myself, the programmer. I
    guess what I'm trying to say is that by adopting a sub-optimal idiom because
    you're afraid you *might* screw up is pulling a rug over the real issues.
    If your debugger is decent - it will be apparent regardless.
     
    Christopher Layne, Oct 5, 2006
    #10
  11. xdevel

    Flash Gordon Guest

    I would not count avoiding automatic arrays as defensive programming. It
    does not prevent you from corrupting anything if you go off the end of
    the array.
    Depends on the quality of your debugging tools and how clearly your code
    is written. In any case, you can easily add statements printing out the
    value of the index before doing the access if you think there is a problem.
     
    Flash Gordon, Oct 5, 2006
    #11
  12. Ark posted:

    Yes, you probably are -- which is why we check back over our code, paying the
    utmost particular attention to these things.
     
    Frederick Gotham, Oct 5, 2006
    #12
  13. Wether an array is dynamically allocated, has static or auto storage
    duration bears little impact on being able to do an off-by-one error.
     
    =?ISO-8859-1?Q?=22Nils_O=2E_Sel=E5sdal=22?=, Oct 5, 2006
    #13
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.