What is the size of a char pointer?

This is a discussion on What is the size of a char pointer? within the C Programming forums, part of the General Programming Boards category; What is the maximum size of a pointer to a char? I went to allocate a char pointer using malloc ...

  1. #1
    Registered User
    Join Date
    Dec 2007
    Posts
    51

    What is the size of a char pointer?

    What is the maximum size of a pointer to a char?

    I went to allocate a char pointer using malloc to the size of 49,152 bytes, but for some reason, when I looked at a memory dump, it only allocated ~1300 bytes in memory.

    Heres my code: (buffer is the pointer that is only allocated this meager amount of ~1300 bytes. I'm opening a file thats 49Kb and for some reason my compiler wont give it that amount of memory to work with. Is this some limitation of C?)

    Code:
    char * store(char filename[])
    {
    	char * buffer;
    	long fileSize = 0;
    	image = fopen(filename,"r");
    	
    	// Obtain the file size
    	fseek(image, 0, SEEK_END);
    	fileSize = ftell(image);
    	rewind(image);
    
    	buffer = malloc(sizeof(char) * fileSize);
    	fread(buffer,1,fileSize,image);
    	fclose(image);
    	
    	buffer = strToHexStr(buffer);
    	
    	return formatOuput(buffer);
    }

  2. #2
    Deathray Engineer MacGyver's Avatar
    Join Date
    Mar 2007
    Posts
    3,211
    You might be confusing yourself here. The size of a char * is probably 4 bytes on a 32-bit machine and 8 bytes on a 64-bit machine, etc. etc..

    How much data a char * can point to is theoretically infinite. When you malloc() memory, all you know is that you're getting a block of memory that is contiguous (or NULL if the allocation failed). How much is allocated depends upon the underlying system.

    What you should be doing is checking to see if fopen() and malloc() fail. To not check those return values is rather silly and just inviting problems to occur.

  3. #3
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,046
    The amount of memory you can malloc() is operating-system dependent. Most operating systems let you allocate at least a few tens of megabytes, if your system has that much free. If your compiler/runtime won't let you do that, you're probably using a very old one. (Turbo C?)

    But perhaps it's something wrong with your code. What happens when you run this program?
    Code:
    #include <stdio.h>
    
    int main(void) {
        size_t size = 1;
        char *p = 0, *temp;
    
        for(;;) {
            temp = realloc(p, size);
            if(!temp) break;
            p = temp;
    
            printf("\rGot &#37;lu bytes", (unsigned long)size);
    
            size *= 2;
        }
    
        free(p);
        printf("\nFailed to get %lu bytes\n", (unsigned long)size);
    
        return 0;
    }
    sizeof(char) is always 1, and so you can leave it out.
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  4. #4
    Deathray Engineer MacGyver's Avatar
    Join Date
    Mar 2007
    Posts
    3,211
    /me slaps dwks for forgetting to #include <stdlib.h>.

  5. #5
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,046
    Oops, I forgot my standard disclaimer:

    This code has not been tested nor proved correct*. I have not tried to run it, I have not even tried to compile it. In fact, I made it up on the spur of the moment in the Quick Reply box.

    It's probably full of bugs, like missing header files. I take no responsibility for bugs with it, e.g. your computer running vvveeeeeeerrrryyyy slowly after executing it.
    * Donald E. Knuth once said: "Beware of bugs in the above code; I have only proved it correct, not tried it.''
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  6. #6
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,344
    > Is this some limitation of C?)
    Lemme guess, another XP user trying to use Turbo C.

    If 1GB is the size of a football field, then the 640K(max) that Turbo C will let you use is the size of a large table.

    No, it's not a limitation of C at all, only of the poor choice of implementation of C.
    Choose one which gives you full access to the whole machine.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  7. #7
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,046
    > Is this some limitation of C?)
    Lemme guess, another XP user trying to use Turbo C.
    That's what I thought at first -- but even Turbo C should let the user allocate "49,152 bytes" of memory, assuming the machine has that much free. Unless the memory model is set to some very small value or something.

    Code:
    buffer = strToHexStr(buffer);
    What function is this? Is the problem in there, perhaps?

    If your code is messing up the memory, then it's entirely possible that you did get 49152 bytes of memory, but that size got corrupted by a buffer overrun or something. In fact, this is almost certainly what happened, assuming malloc() didn't return 0.

    So, post the code to strToHexStr().
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Code review
    By Elysia in forum C++ Programming
    Replies: 71
    Last Post: 05-13-2008, 09:42 PM
  2. An exercise in optimization
    By Prelude in forum Contests Board
    Replies: 10
    Last Post: 04-29-2005, 03:06 PM
  3. Half-life SDK, where are the constants?
    By bennyandthejets in forum Game Programming
    Replies: 29
    Last Post: 08-25-2003, 11:58 AM
  4. simulate Grep command in Unix using C
    By laxmi in forum C Programming
    Replies: 6
    Last Post: 05-10-2002, 04:10 PM
  5. Strings are V important...
    By NANO in forum C++ Programming
    Replies: 15
    Last Post: 04-14-2002, 11:57 AM

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