pointer-to-pointer to char

Discussion in 'C Programming' started by Jack, May 28, 2006.

  1. Jack

    Jack Guest

    The following code can be compiled. But When I run it, it causes
    "Segmentation fault".

    int main(){
    char **c1;

    *c1 = "HOW"; // LINE1

    ++(*c1);
    *c1 = "ARE";

    ++(*c1);
    *c1 = "YOU";
    }

    c1 is a pointer-to-pointer to char. How to initialize c1 to three
    strings: "HOW", "ARE", "YOU"?

    Thanks a lot.
     
    Jack, May 28, 2006
    #1
    1. Advertising

  2. Jack

    Ian Collins Guest

    Jack wrote:
    > The following code can be compiled. But When I run it, it causes
    > "Segmentation fault".
    >
    > int main(){
    > char **c1;
    >
    > *c1 = "HOW"; // LINE1
    >

    c1 doesn't point to anything...
    >
    > c1 is a pointer-to-pointer to char. How to initialize c1 to three
    > strings: "HOW", "ARE", "YOU"?
    >

    char *c1[] = { "HOW", "ARE", "YOU" };

    --
    Ian Collins.
     
    Ian Collins, May 28, 2006
    #2
    1. Advertising

  3. Jack

    Ian Collins Guest

    Ian Collins wrote:
    > Jack wrote:
    >
    >>The following code can be compiled. But When I run it, it causes
    >>"Segmentation fault".
    >>
    >>int main(){
    >> char **c1;
    >>
    >> *c1 = "HOW"; // LINE1
    >>

    >
    > c1 doesn't point to anything...
    >
    >>c1 is a pointer-to-pointer to char. How to initialize c1 to three
    >>strings: "HOW", "ARE", "YOU"?
    >>

    >
    > char *c1[] = { "HOW", "ARE", "YOU" };
    >

    I should have said

    const char *c1[] = { "HOW", "ARE", "YOU" };

    --
    Ian Collins.
     
    Ian Collins, May 28, 2006
    #3
  4. Jack

    Joe Wright Guest

    Jack wrote:
    > The following code can be compiled. But When I run it, it causes
    > "Segmentation fault".
    >
    > int main(){
    > char **c1;
    >
    > *c1 = "HOW"; // LINE1


    Boom! Crash and burn! c1 is not initialized and *c1 is garbage.
    >
    > ++(*c1);
    > *c1 = "ARE";
    >
    > ++(*c1);
    > *c1 = "YOU";
    > }
    >
    > c1 is a pointer-to-pointer to char. How to initialize c1 to three
    > strings: "HOW", "ARE", "YOU"?
    >
    > Thanks a lot.
    >

    #include <stdlib.h>

    char **c1 = malloc(3 * sizeof *c1);
    c1[0] = "HOW";
    c1[1] = "ARE";
    c1[2] = "YOU";

    --
    Joe Wright
    "Everything should be made as simple as possible, but not simpler."
    --- Albert Einstein ---
     
    Joe Wright, May 28, 2006
    #4
  5. Jack

    Tomás Guest


    > char **c1;
    >
    > *c1 = "HOW";



    Most (if not all) novices make this mistake at some stage, but it doesn't
    take long before you can spot it from a mile away. Here's a sample:

    char *p;

    The variable "p" stores a memory address (at which resides a char). You
    didn't initialise it, so it contains white noise. Let's say its value is:
    8374534.

    *p = 'a';


    Now you dereference this pointer value, and write to the memory. So
    you're writing 'a' to the memory location: 8374534.

    You have to give "p" a legitimate value:

    char k;

    char *p = &k;


    Let's say that k is stored at the memory address: 234873. Now p is
    storing the value: 234873. This is a legitimate memory location to
    access:

    *p = 'e';


    The crux of the matter is this: When you define a pointer variable,
    you're DON'T actually allocate memory for the variable which it points
    to. But it's easist to think along the following lines: A "char*" stores
    a memory address.


    -Tomás
     
    Tomás, May 28, 2006
    #5
  6. Jack

    Joe Wright Guest

    Tomás wrote:
    >> char **c1;
    >>
    >> *c1 = "HOW";

    >
    >
    > Most (if not all) novices make this mistake at some stage, but it doesn't
    > take long before you can spot it from a mile away. Here's a sample:
    >
    > char *p;
    >
    > The variable "p" stores a memory address (at which resides a char). You
    > didn't initialise it, so it contains white noise. Let's say its value is:
    > 8374534.
    >
    > *p = 'a';


    The value of an unitialized pointer is of no interest. The above
    statement is undefined behavior and may cause segment fault or other error.
    >
    >
    > Now you dereference this pointer value, and write to the memory. So
    > you're writing 'a' to the memory location: 8374534.
    >

    Please see my comment above.

    > You have to give "p" a legitimate value:
    >
    > char k;
    >
    > char *p = &k;
    >

    That's better. p holds the address of k and k is sufficient to hold 'e'.
    >
    > Let's say that k is stored at the memory address: 234873. Now p is
    > storing the value: 234873. This is a legitimate memory location to
    > access:
    >

    Again, the actual value of a pointer is of no interest.

    > *p = 'e';
    >

    This works and now (k == 'e') is true.
    >
    > The crux of the matter is this: When you define a pointer variable,
    > you're DON'T actually allocate memory for the variable which it points
    > to. But it's easist to think along the following lines: A "char*" stores
    > a memory address.
    >

    More correctly, an object of type char* may contain the address of an
    object of type char.
    >
    > -Tomás



    --
    Joe Wright
    "Everything should be made as simple as possible, but not simpler."
    --- Albert Einstein ---
     
    Joe Wright, May 28, 2006
    #6
  7. Jack

    Tomás Guest

    Joe Wright posted:


    >> The variable "p" stores a memory address (at which resides a char).
    >> You didn't initialise it, so it contains white noise. Let's say its
    >> value is: 8374534.
    >>
    >> *p = 'a';

    >
    > The value of an unitialized pointer is of no interest.



    It is for the purpose of my tutorial -- it gives the original poster a
    concrete, down-to-earth example of what's going on. When you don't
    initialise a variable, it sort of has a random value (which may not even
    be a valid bit-pattern for the given type).


    > The above
    > statement is undefined behavior and may cause segment fault or other
    > error.



    Congratulations, you understand.


    > That's better. p holds the address of k and k is sufficient to hold
    > 'e'.



    Should I presume that the remainder of your post simply repeats every
    point I made in my previous post?


    > This works and now (k == 'e') is true.



    An inaccurate method of testing. I bet you I could get the following to
    work on my system:

    char *p;

    *p = 'e';

    if ( *p == 'e' ) NaivelyIndicateSuccess();


    >> The crux of the matter is this: When you define a pointer variable,
    >> you're DON'T actually allocate memory for the variable which it
    >> points to. But it's easist to think along the following lines: A
    >> "char*" stores a memory address.
    >>

    > More correctly, an object of type char* may contain the address of an
    > object of type char.



    (Maybe I'm getting mixed up with C and C++ here, but in C++, you can use
    a char* to access ANY memory. Would you have to use an unsigned char* in
    C?)


    -Tomás
     
    Tomás, May 28, 2006
    #7
  8. Jack

    Joe Wright Guest

    Tomás wrote:
    > Joe Wright posted:
    >
    >
    >>> The variable "p" stores a memory address (at which resides a char).
    >>> You didn't initialise it, so it contains white noise. Let's say its
    >>> value is: 8374534.
    >>>
    >>> *p = 'a';

    >> The value of an unitialized pointer is of no interest.

    >
    >
    > It is for the purpose of my tutorial -- it gives the original poster a
    > concrete, down-to-earth example of what's going on. When you don't
    > initialise a variable, it sort of has a random value (which may not even
    > be a valid bit-pattern for the given type).
    >
    >
    >> The above
    >> statement is undefined behavior and may cause segment fault or other
    >> error.

    >
    >
    > Congratulations, you understand.
    >
    >
    >> That's better. p holds the address of k and k is sufficient to hold
    >> 'e'.

    >
    >
    > Should I presume that the remainder of your post simply repeats every
    > point I made in my previous post?
    >
    >
    >> This works and now (k == 'e') is true.

    >
    >
    > An inaccurate method of testing. I bet you I could get the following to
    > work on my system:
    >
    > char *p;
    >
    > *p = 'e';
    >
    > if ( *p == 'e' ) NaivelyIndicateSuccess();
    >

    But we agree that this is undefined, don't we?
    >
    >>> The crux of the matter is this: When you define a pointer variable,
    >>> you're DON'T actually allocate memory for the variable which it
    >>> points to. But it's easist to think along the following lines: A
    >>> "char*" stores a memory address.
    >>>

    >> More correctly, an object of type char* may contain the address of an
    >> object of type char.

    >
    >
    > (Maybe I'm getting mixed up with C and C++ here, but in C++, you can use
    > a char* to access ANY memory. Would you have to use an unsigned char* in
    > C?)
    >

    Yes, 'unsigned char*' is the method to access any byte in memory in C.
    Since C89 we have 'void*' to hold any memory address but it can't be
    used to access memory directly.
    >
    > -Tomás



    --
    Joe Wright
    "Everything should be made as simple as possible, but not simpler."
    --- Albert Einstein ---
     
    Joe Wright, May 28, 2006
    #8
  9. Jack

    Tomás Guest

    Joe Wright posted:


    >> char *p;
    >>
    >> *p = 'e';
    >>
    >> if ( *p == 'e' ) NaivelyIndicateSuccess();
    >>

    > But we agree that this is undefined, don't we?



    Yes of course. (I didn't want to state the obvious).


    -Tomás
     
    Tomás, May 28, 2006
    #9
  10. Jack

    Jack Guest

    Thanks a lot.
    But why the following code works well?
    int *p;
    *p = 5;

    Moreover, I find that many textbooks use the following code to
    initialize a char pointer:
    char *c;
    c = "test";

    Is it wrong?

    Thanks.
     
    Jack, May 28, 2006
    #10
  11. Jack

    Ben Pfaff Guest

    "Jack" <> writes:

    > But why the following code works well?
    > int *p;
    > *p = 5;


    There's always the chance that an uninitialized pointer happens
    to point to memory that, when modified, doesn't exhibit any
    immediately bad behavior. That's bad: it means that the error
    doesn't show up in testing, or perhaps that it makes the error
    look like it's in some unrelated part of your program.

    > Moreover, I find that many textbooks use the following code to
    > initialize a char pointer:
    > char *c;
    > c = "test";
    >
    > Is it wrong?


    No, this is correct code[*]. The difference here is that this
    statement sets the value `c'. The former code does not set the
    value of `c'; rather, it *uses* the (uninitialized) value of `c',
    by dereferencing it.

    [*] Although it would be better to declare `c' as type `const
    char *', because literal strings are non-modifiable.
    --
    "In My Egotistical Opinion, most people's C programs should be indented six
    feet downward and covered with dirt." -- Blair P. Houghton
     
    Ben Pfaff, May 28, 2006
    #11
  12. Jack

    Tomás Guest

    Jack posted:

    > Thanks a lot.
    > But why the following code works well?
    > int *p;
    > *p = 5;



    Learn to be more articulate when asking questions.


    Question: Why does it compile?

    Answer: Because there's nothing in the Standard which it must not
    compile.


    Question: When I run the executable, why does it run normally without
    error?

    Answer: Because you're luck (or unlucky). Your system simply isn't
    complaining about you accessing memory which isn't yours to access. If
    you've got a Disk Format Program running at the same time, you may alter
    its boolean value which determines whether it should format the C drive.


    > Moreover, I find that many textbooks use the following code to
    > initialize a char pointer:
    > char *c;
    > c = "test";



    Stupid, but not wrong. I'm too lazy to explain why though. Go to:

    http://www.possibility.com/Cpp/const.html

    and do a text search for "undefined, modifying static buffer!!!"


    -Tomás
     
    Tomás, May 28, 2006
    #12
  13. Jack

    Jack Guest

    What is the problem with the following code?

    int **p1;
    int a1[] = {2,3,4};
    int a2[] = {22,33};
    int a3[] = {22,33,44,55};

    int *b1, *b2, *b3;

    b1 = a1;
    b2 = a2;
    b3 = a3;

    p1 = &b1;
    p1++;
    p1=&b2;
    p1++;
    p1=&b3;

    p1 = p1-2;

    for(int i = 0; i < 3; i++){
    std::cout <<"*((*p1)+"<<i<<"): "<< *((*p1)+i)<<std::endl; //LINE1
    }

    p1++;
    for(int i = 0; i < 2; i++){
    std::cout <<"*(*(p1+1)+"<<i<<"): "<< *(*(p1)+i)<<std::endl; //LINE2
    }


    LINE1 prints unexpected numbers. LINE2 causes "Segmentation fault".
    Why?

    Thanks.
     
    Jack, May 29, 2006
    #13
  14. Jack

    Tomás Guest

    Not necessarily contiguous

    Jack posted:


    > int **p1;



    OK.


    > int a1[] = {2,3,4};



    OK.


    > int a2[] = {22,33};



    OK.


    > int a3[] = {22,33,44,55};



    OK.


    >
    > int *b1, *b2, *b3;



    OK.


    > b1 = a1;
    > b2 = a2;
    > b3 = a3;



    OK.


    > p1 = &b1;



    OK.


    > p1++;



    p1 now contains garbage.


    > p1=&b2;



    OK.


    > p1++;



    p1 now contains garbage.


    > p1=&b3;



    OK.


    > p1 = p1-2;



    p1 now contain garbage.


    > LINE1 prints unexpected numbers. LINE2 causes "Segmentation fault".
    > Why?



    Your code makes the unfounded presumption that b1, b2, and b3 are
    contiguous in memory. What you want is something like:

    int *array_pointers[3];

    #define b1 (*array_pointers)
    #define b2 (array_pointers[1])
    #define b3 (array_pointers[2])


    Here's the revised code:



    int main(void)
    {

    int **p1;
    int a1[] = {2,3,4};
    int a2[] = {22,33};
    int a3[] = {22,33,44,55};

    int *array_pointers[3];

    #define b1 (*array_pointers)
    #define b2 (array_pointers[1])
    #define b3 (array_pointers[2])

    b1 = a1;
    b2 = a2;
    b3 = a3;

    p1 = &b1;
    p1++;
    p1=&b2;
    p1++;
    p1=&b3;

    p1 = p1-2;
    }


    As for using C standard output rather than C++ standard output... I'll
    leave that one up to you.

    -Tomás
     
    Tomás, May 29, 2006
    #14
  15. Jack

    Jack Guest

    Re: Not necessarily contiguous

    Thanks a lot. I tested your code. It works well!
    Do you mean that the pointers stored in p1, (p1+1) and (p1+2) must be
    contiguous in memory?
    My thought is that p1, (p1+1) and (p1+2) are contiguous in memory. So
    even if b1, b2 and b3 in my code are not contiguous in memory, I can
    still access it through p1, (p1+1) and (p1+2). I must be wrong. Why?

    To make it easy to read, part of my code is below:

    int **p1;
    int a1[] = {2,3,4};
    int a2[] = {22,33};
    int a3[] = {22,33,44,55};

    int *b1, *b2, *b3;

    b1 = a1;
    b2 = a2;
    b3 = a3;

    p1 = &b1;
    p1++;
    p1=&b2;
    p1++;
    p1=&b3;

    p1 = p1-2;


    Thanks.
     
    Jack, May 29, 2006
    #15
  16. "Jack" <> writes:
    > What is the problem with the following code?
    >
    > int **p1;

    [snip]
    > for(int i = 0; i < 3; i++){
    > std::cout <<"*((*p1)+"<<i<<"): "<< *((*p1)+i)<<std::endl; //LINE1
    > }

    [snip]

    There are at least two major problems.

    1. It's not a complete program, though you could easily have made it
    one (which would have made it easier for us to help).

    2. It's not C, it's C++.

    Please take the time to post a complete, self-contained program.

    --
    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, May 29, 2006
    #16
  17. Re: Not necessarily contiguous

    On 2006-05-29, Jack <> wrote:
    > Thanks a lot. I tested your code. It works well!
    > Do you mean that the pointers stored in p1, (p1+1) and (p1+2) must be
    > contiguous in memory?
    > My thought is that p1, (p1+1) and (p1+2) are contiguous in memory. So
    > even if b1, b2 and b3 in my code are not contiguous in memory, I can
    > still access it through p1, (p1+1) and (p1+2). I must be wrong. Why?
    >

    p1+1 points to the memory location immediately after the original p1.
    Here's a small diagram to help:

    --------------------
    | p1 | p1+1 | p1+2 |
    --------------------
    | | |
    --------------------------------
    | b1 | ? | ? | b2 | b3 |
    --------------------------------

    That is a very artificial example, as b1, b2, and b3 could be
    millions of bytes away from each other! However, p1+1 will always
    point to the place after p1.


    > To make it easy to read, part of my code is below:
    >
    > int **p1;
    > int a1[] = {2,3,4};
    > int a2[] = {22,33};
    > int a3[] = {22,33,44,55};
    >
    > int *b1, *b2, *b3;
    >
    > b1 = a1;
    > b2 = a2;
    > b3 = a3;
    >
    > p1 = &b1;
    > p1++;
    > p1=&b2;
    > p1++;
    > p1=&b3;
    >
    > p1 = p1-2;
    >

    I've left that for people to comment.


    --
    Andrew Poelstra < http://www.wpsoftware.net/blog >
    To email me, use "apoelstra" at the above address.
    It's just like stealing teeth from a baby.
     
    Andrew Poelstra, May 29, 2006
    #17
  18. Jack

    Jack Guest

    Re: Not necessarily contiguous

    Andrew Poelstra wrote:
    > On 2006-05-29, Jack <> wrote:
    > > Thanks a lot. I tested your code. It works well!
    > > Do you mean that the pointers stored in p1, (p1+1) and (p1+2) must be
    > > contiguous in memory?
    > > My thought is that p1, (p1+1) and (p1+2) are contiguous in memory. So
    > > even if b1, b2 and b3 in my code are not contiguous in memory, I can
    > > still access it through p1, (p1+1) and (p1+2). I must be wrong. Why?
    > >

    > p1+1 points to the memory location immediately after the original p1.
    > Here's a small diagram to help:
    >
    > --------------------
    > | p1 | p1+1 | p1+2 |
    > --------------------
    > | | |
    > --------------------------------
    > | b1 | ? | ? | b2 | b3 |
    > --------------------------------
    >
    > That is a very artificial example, as b1, b2, and b3 could be
    > millions of bytes away from each other! However, p1+1 will always
    > point to the place after p1.


    Do you mean that the memory that p1, (p1+1) and (p1+2) point to must be
    contiguous?
    p1, (p1+1) and (p1+2) are contiguous. b1's address is stored in p1,
    b2's address is stored in (p1+1), and b3's address is stored in (p1+2).
    Why b1, b2, and b3 must be contiguous? Thanks.

    Jack


    >
    >
    > > To make it easy to read, part of my code is below:
    > >
    > > int **p1;
    > > int a1[] = {2,3,4};
    > > int a2[] = {22,33};
    > > int a3[] = {22,33,44,55};
    > >
    > > int *b1, *b2, *b3;
    > >
    > > b1 = a1;
    > > b2 = a2;
    > > b3 = a3;
    > >
    > > p1 = &b1;
    > > p1++;
    > > p1=&b2;
    > > p1++;
    > > p1=&b3;
    > >
    > > p1 = p1-2;
    > >

    > I've left that for people to comment.
    >
    >
    > --
    > Andrew Poelstra < http://www.wpsoftware.net/blog >
    > To email me, use "apoelstra" at the above address.
    > It's just like stealing teeth from a baby.
     
    Jack, May 29, 2006
    #18
  19. Re: Not necessarily contiguous

    On 2006-05-29, Jack <> wrote:
    >
    > Andrew Poelstra wrote:
    >> On 2006-05-29, Jack <> wrote:
    >> > Thanks a lot. I tested your code. It works well!
    >> > Do you mean that the pointers stored in p1, (p1+1) and (p1+2) must be
    >> > contiguous in memory?
    >> > My thought is that p1, (p1+1) and (p1+2) are contiguous in memory. So
    >> > even if b1, b2 and b3 in my code are not contiguous in memory, I can
    >> > still access it through p1, (p1+1) and (p1+2). I must be wrong. Why?
    >> >

    >> p1+1 points to the memory location immediately after the original p1.
    >> Here's a small diagram to help:
    >>
    >> --------------------
    >> | p1 | p1+1 | p1+2 |
    >> --------------------
    >> | | |
    >> --------------------------------
    >> | b1 | ? | ? | b2 | b3 |
    >> --------------------------------
    >>
    >> That is a very artificial example, as b1, b2, and b3 could be
    >> millions of bytes away from each other! However, p1+1 will always
    >> point to the place after p1.

    >
    > Do you mean that the memory that p1, (p1+1) and (p1+2) point to must be
    > contiguous?
    > p1, (p1+1) and (p1+2) are contiguous. b1's address is stored in p1,
    > b2's address is stored in (p1+1), and b3's address is stored in (p1+2).
    > Why b1, b2, and b3 must be contiguous? Thanks.
    >

    If b1's address is stored in p1, you have double indirection. I'm not
    sure that that is what you mean or want, but here's an expaination:

    ---------------------------
    | p1 | p1+1 | p1+2 |
    ---------------------------
    | | |
    ---------------------------
    | *p1 | *(p1+1) | *(p1+2) |
    ---------------------------
    | | \-----------\
    | | |
    | \-------------\ |
    --------------------------------
    | b1 | ? | ? | b2 | b3 |
    --------------------------------

    In this case, *p1, *(p1+1), and *(p1+2) are all pointers in themselves.
    I recommend you avoid double indirection until you have a firm grasp
    on other aspects of pointers.
     
    Andrew Poelstra, May 29, 2006
    #19
  20. Jack

    Jack Guest

    Re: Not necessarily contiguous

    Andrew Poelstra wrote:
    > On 2006-05-29, Jack <> wrote:
    > >
    > > Andrew Poelstra wrote:
    > >> On 2006-05-29, Jack <> wrote:
    > >> > Thanks a lot. I tested your code. It works well!
    > >> > Do you mean that the pointers stored in p1, (p1+1) and (p1+2) must be
    > >> > contiguous in memory?
    > >> > My thought is that p1, (p1+1) and (p1+2) are contiguous in memory. So
    > >> > even if b1, b2 and b3 in my code are not contiguous in memory, I can
    > >> > still access it through p1, (p1+1) and (p1+2). I must be wrong. Why?
    > >> >
    > >> p1+1 points to the memory location immediately after the original p1.
    > >> Here's a small diagram to help:
    > >>
    > >> --------------------
    > >> | p1 | p1+1 | p1+2 |
    > >> --------------------
    > >> | | |
    > >> --------------------------------
    > >> | b1 | ? | ? | b2 | b3 |
    > >> --------------------------------
    > >>
    > >> That is a very artificial example, as b1, b2, and b3 could be
    > >> millions of bytes away from each other! However, p1+1 will always
    > >> point to the place after p1.

    > >
    > > Do you mean that the memory that p1, (p1+1) and (p1+2) point to must be
    > > contiguous?
    > > p1, (p1+1) and (p1+2) are contiguous. b1's address is stored in p1,
    > > b2's address is stored in (p1+1), and b3's address is stored in (p1+2).
    > > Why b1, b2, and b3 must be contiguous? Thanks.
    > >

    > If b1's address is stored in p1, you have double indirection. I'm not
    > sure that that is what you mean or want, but here's an expaination:
    >
    > ---------------------------
    > | p1 | p1+1 | p1+2 |
    > ---------------------------
    > | | |
    > ---------------------------
    > | *p1 | *(p1+1) | *(p1+2) |
    > ---------------------------
    > | | \-----------\
    > | | |
    > | \-------------\ |
    > --------------------------------
    > | b1 | ? | ? | b2 | b3 |
    > --------------------------------
    >
    > In this case, *p1, *(p1+1), and *(p1+2) are all pointers in themselves.
    > I recommend you avoid double indirection until you have a firm grasp
    > on other aspects of pointers.


    Thank you for your creative figure using text format.
    The figure below expresses what I mean. Why it does not work?

    ------------------------------------
    | p1 | p1+1 | p1+2 |
    ----------------------------------
    | | |
    | | \--------\
    | | |
    | \-------------\ |
    -------------------------------------
    | b1 | ? | ? | b2 | b3 |
    -------------------------------------

    p1 = &b1;
    p1++;
    p1 = &b2;
    p1++;
    p1 = &b3;

    p1 = p1-2;

    Does p1 point to b1 now? I can not figure out what the problem is.

    Thanks a lot.
     
    Jack, May 30, 2006
    #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. wwj
    Replies:
    7
    Views:
    581
  2. wwj
    Replies:
    24
    Views:
    2,548
    Mike Wahler
    Nov 7, 2003
  3. Ben Pfaff
    Replies:
    5
    Views:
    490
    Tristan Miller
    Jan 17, 2004
  4. Steffen Fiksdal

    void*, char*, unsigned char*, signed char*

    Steffen Fiksdal, May 8, 2005, in forum: C Programming
    Replies:
    1
    Views:
    607
    Jack Klein
    May 9, 2005
  5. lovecreatesbeauty
    Replies:
    1
    Views:
    1,099
    Ian Collins
    May 9, 2006
Loading...

Share This Page