Program output when using pointers is odd

This is a discussion on Program output when using pointers is odd within the C Programming forums, part of the General Programming Boards category; I get an odd output when I run a program I wrote. This program is just a basic pointer excersize ...

  1. #1
    Registered User skringla's Avatar
    Join Date
    Nov 2008
    Posts
    8

    Program output when using pointers is odd

    I get an odd output when I run a program I wrote. This program is just a basic pointer excersize that I thought up.
    Code:
    #include <stdio.h>
    #include <string.h>
    
    int main(int argc, char** argv)
    {
    	char** buffarray;
    	char b[20] = "hello world";
    	buffarray[0] = b;
    	printf("%s\n", buffarray[0]);
    	return 0;
    }
    this is the output
    thomas@skringla:~/projects$ ./test
    hello world
    6554:
    6554: runtime linker statistics:
    6554: final number of relocations: 84
    6554: final number of relocations from cache: 3
    thomas@skringla:~/projects$
    when compliled there isn't even a warning.
    my compliler version in case that helps
    Code:
    thomas@skringla:~/projects$ gcc -v
    Using built-in specs.
    Target: x86_64-linux-gnu
    Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
    Thread model: posix
    gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3)

  2. #2
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Well to start with you have not allocated any memory at all for buffarray.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  3. #3
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,185
    Following on to Mr. 27's comment, you could assign buffarray (if it was a single char*) to b just fine -- that wouldn't require anything extra. But buffarray[0] tries to follow the value of buffarray, which is currently pointing to The Land of Uninitialized Pointers, and then trying to assign b to whatever address is found there.

  4. #4
    Registered User skringla's Avatar
    Join Date
    Nov 2008
    Posts
    8
    Isn't the land of uninitialized pointer in new jersey?

  5. #5
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,185
    Quote Originally Posted by skringla View Post
    Isn't the land of uninitialized pointer in new jersey?
    Yes.

  6. #6
    Registered User skringla's Avatar
    Join Date
    Nov 2008
    Posts
    8
    Quote Originally Posted by MK27 View Post
    Well to start with you have not allocated any memory at all for buffarray.
    Then what am I still doing wrong?
    Code:
    #include <stdio.h>
    #include <string.h>
    
    int main(int argc, char** argv)
    {
    	char** buffarray;
    	char* bb;
    	char b[20] = "hello world";
    	bb = b;
    	buffarray[0] = bb;
    	printf("%s\n", buffarray[0]);
    	return 0;
    }
    It would seem that new jersey has called again. some where in the area of uninititialized pointers.
    lookup 0x0000000000400000 0x00000000000002b8 -> 0x00007ffacee51000 0x00000000000650b0 /1 puts
    hello world
    9813:
    9813: runtime linker statistics:
    9813: final number of relocations: 84
    9813: final number of relocations from cache: 3
    thomas@skringla:~/projects$

  7. #7
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,185
    Quote Originally Posted by skringla View Post
    Then what am I still doing wrong?
    Code:
    #include <stdio.h>
    #include <string.h>
    
    int main(int argc, char** argv)
    {
    	char** buffarray;
    	char* bb;
    	char b[20] = "hello world";
    	bb = b;
    	buffarray[0] = bb;
    	printf("%s\n", buffarray[0]);
    	return 0;
    }
    It would seem that new jersey has called again. some where in the area of uninititialized pointers.
    buffarray[0] still doesn't exist. buffarray points to New Jersey; trying to dereference it (with the [0] notation) will then call forth the demons.

  8. #8
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    20,973
    This makes the char pointer bb point to the first char in the array b:
    Code:
    bb = b;
    Well and good. Now, this makes the char pointer buffarray[0] point to what bb points to:
    Code:
    buffarray[0] = bb;
    Oh wait, buffarray is a pointer to a char pointer (that presumably is the first char pointer in an array of char pointers)... but it does not point to anything (yet). As such, buffarray[0] accesses a pointer that does not exist, and that is a mistake.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  9. #9
    Registered User skringla's Avatar
    Join Date
    Nov 2008
    Posts
    8
    doesn't that defeat the purpose of a pointer to a pointer, the whole idea is that buffarray is a array of pointers pointing to whole strings and not just individual characters. Like when you use argv[1] to access the first argument of the program you are running. It doesn't give back just the "-" but the whole argument "-l" (say program "ls -l")

  10. #10
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by skringla View Post
    doesn't that defeat the purpose of a pointer to a pointer, the whole idea is that buffarray is a array of pointers pointing to whole strings and not just individual characters. Like when you use argv[1] to access the first argument of the program you are running. It doesn't give back just the "-" but the whole argument "-l" (say program "ls -l")
    No, each level of pointer needs to point to a valid memory location.

    In this case, there is no memory for "bufferarray".

    If you do something like this:
    Code:
    char *backbuffer[10];
    char **bufferarray = backbuffer;
    then you can use bufferarray[0..9].

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  11. #11
    Registered User C_ntua's Avatar
    Join Date
    Jun 2008
    Posts
    1,853
    Quote Originally Posted by skringla View Post
    doesn't that defeat the purpose of a pointer to a pointer, the whole idea is that buffarray is a array of pointers pointing to whole strings and not just individual characters. Like when you use argv[1] to access the first argument of the program you are running. It doesn't give back just the "-" but the whole argument "-l" (say program "ls -l")
    argv though is properly allocated. This would be valid:
    Code:
    #include<stdlib.h>
    #include <stdio.h>
    #include <string.h>
    
    int main(int argc, char** argv)
    {
    	char** buffarray = malloc(sizeof(char*));;
    	char b[20] = "hello world";
    	buffarray[0] = b;
    	printf("&#37;s\n", buffarray[0]);
    	return 0;
    }
    Now, you have 1 spaces of memory for buffarray. You can thus use buffarray[0]
    Again, you wouldn't be able to use buffarray[0][0] prior to buffaray = b, because for that you would need
    Code:
    buffarray[0] = malloc(sizeof(char));
    Allocating memory is different than assigning a value to a pointer. Another way to go would be something like
    Code:
    char* buffarray[20];
    Now you allocate an array of 20 char*

    This is how it looks in the memory when you do char** buffarray

    Address Value Name
    0x12312 (undefined) buffarray

    If you do buffarray = malloc(sizeof(char*));

    Address Value Name
    0x12312 0x12358 buffarray
    0x12358 undef (no name, just value returned from malloc)

    Now, buffarray[0] means *(buffarray + 0), that is *(0x12312 + 0) thus *(0x12312). Which is 0x12358 (the value of the address 0x12312, known as buffarray).
    That address exists, it is allocated, so you can use it. When you do buffarray[0] = b then you will have:

    Address Value Name
    0x12312 0x12358 buffarray
    0x12358 value of b (no name, just value returned from malloc)


    P.S. Haha. In New Jersey. We all know that's a lie parents tell to their children. Something like Santa Claus

  12. #12
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,171
    You forgot to free.
    But I like to do it the easy way:

    Code:
    char array[] = "My 1337 z0mg text!";
    char* p;
    char** p2p = &p;
    p2p[0] = array;
    Tada!
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.
    For information on how to enable C++11 on your compiler, look here.
    よく聞くがいい!私は天才だからね! ^_^

  13. #13
    Registered User C_ntua's Avatar
    Join Date
    Jun 2008
    Posts
    1,853
    Code:
    const char[] = "The Land of Initialized Pointers";
    a small detail, but const illustrates more the string literal

    If you understand the difference between your initial code and Elysia's code then you understand why you got errors

  14. #14
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,171
    You only really need const if you aren't going to modify the array or if it's a string literal, but since you are really initializing a char array, you don't really need const there.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.
    For information on how to enable C++11 on your compiler, look here.
    よく聞くがいい!私は天才だからね! ^_^

  15. #15
    Registered User skringla's Avatar
    Join Date
    Nov 2008
    Posts
    8
    I think I have it now. I am going to try more complex pointer stuff now that I understand them better. Thank you to every one who responded and especially Elysia because she made me understand it.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Help C program that reads Odd numbers and evens
    By Cyberman86 in forum C Programming
    Replies: 4
    Last Post: 02-27-2009, 10:59 AM
  2. program looping with final output
    By hebali in forum C Programming
    Replies: 24
    Last Post: 02-28-2008, 09:58 AM
  3. Pointers program
    By Jamina in forum C++ Programming
    Replies: 3
    Last Post: 08-06-2003, 02:31 PM
  4. Replies: 4
    Last Post: 03-09-2002, 12:22 PM
  5. I need help with pointers in my program
    By CheeseMonkey in forum C++ Programming
    Replies: 3
    Last Post: 12-01-2001, 08:31 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21