A little rusty on pointers to pointers

Discussion in 'C Programming' started by Sam, Sep 24, 2008.

  1. Sam

    Sam Guest

    Hi there. I hope this code is standard C. I think it is. Anyway, I
    haven't used C in a Looooooong time and am a little rusty on pointers.
    I am wondering why "buff" is a pointer to a pointer instead of just
    "*buff". I'm also not really sure about the language of pointers. Is
    it correct to say "pointer to a pointer to buff" or "double pointer to
    buff" or what? If you can help me with this, you have my thanks...

    REM --- *Code Below* ---

    void LoadFileIntoMemory(const char *name, void **buff, int *length)
    {
    FILE *fp = fopen(name, "rb");

    fseek(fp, 0, SEEK_END);
    *length = ftell(fp);
    fseek(fp, 0, SEEK_SET);

    *buff = malloc(*length);
    fread(*buff, *length, 1, fp);

    fclose(fp);
    }

    REM --- *End Code* ---
    Sam, Sep 24, 2008
    #1
    1. Advertising

  2. Sam <> writes:
    > Hi there. I hope this code is standard C. I think it is. Anyway, I
    > haven't used C in a Looooooong time and am a little rusty on
    > pointers. I am wondering why "buff" is a pointer to a pointer instead
    > of just "*buff". I'm also not really sure about the language of
    > pointers. Is it correct to say "pointer to a pointer to buff" or
    > "double pointer to buff" or what? If you can help me with this, you
    > have my thanks...
    >
    > REM --- *Code Below* ---
    >
    > void LoadFileIntoMemory(const char *name, void **buff, int *length)
    > {
    > FILE *fp = fopen(name, "rb");
    >
    > fseek(fp, 0, SEEK_END);
    > *length = ftell(fp);
    > fseek(fp, 0, SEEK_SET);
    >
    > *buff = malloc(*length);
    > fread(*buff, *length, 1, fp);
    >
    > fclose(fp);
    > }
    >
    > REM --- *End Code* ---


    As you probably know, but I'll emphasize it anyway, all function
    arguments are passed by value. A parameter is a local variable,
    containing (at least initially) a copy of the argument value.
    Modifying the parameter object (name, buff, or length in this case)
    only modifies this local variable, which ceases to exist when the
    function returns.

    Consider a call to this function:

    void *buff;
    int length;
    LoadFileIntoMemory("foo.dat", &buff, &length);

    The function passes back two pieces of information to the caller: the
    location where it stored the data, and the length of the data.

    The location of the data is represented as a void*; the length of the
    data is represented as an int. So the caller has to pass in *a
    pointer to* a void*, and *a pointer to* an int, so that the function
    knows where to store the void* and int values that the caller needs.

    Suppose the arguments were just a void* and an int:

    void LoadFileIntoMemory(..., void **buff, int length);
    {
    length = ftell(fp);
    ...
    buff = malloc(length);
    }

    Then the values of length and buff would be lost.

    As for terminology, "pointer to pointer to void" is fine (it's not a
    pointer to pointer to buff; buff *is* the pointer). The term "double
    pointer" should be avoided, unless you're talking about a double*
    (i.e., a pointer to a floating-point object).

    As for the function itself:

    There is no error checking, and no mechanism for the function to
    report an error to its caller. What if fopen() fails for any of a
    variety of reasons? What if fseek() fails because you passed it the
    name of the keyboard device? What if malloc fails because you've run
    out of memory? Likewise for fread and fclose.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Sep 24, 2008
    #2
    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. M. Norton

    Rusty with Configurations

    M. Norton, Mar 16, 2010, in forum: VHDL
    Replies:
    9
    Views:
    695
    Martin Thompson
    Mar 23, 2010
  2. M. Norton
    Replies:
    7
    Views:
    598
  3. David Hearn

    Rusty on the ASP. Array Question

    David Hearn, Aug 16, 2006, in forum: ASP General
    Replies:
    2
    Views:
    256
    David Hearn
    Aug 16, 2006
  4. Tricky

    Re: Really Rusty in VHDL...

    Tricky, Mar 30, 2012, in forum: VHDL
    Replies:
    1
    Views:
    744
    MBodnar
    Mar 30, 2012
  5. KJ
    Replies:
    1
    Views:
    734
Loading...

Share This Page