Thread: Pointers pointers pointers...

  1. #1
    Registered /usr
    Join Date
    Aug 2001
    Location
    Newport, South Wales, UK
    Posts
    1,273

    Unhappy Pointers pointers pointers...

    Hi,
    This should be an easy one, needless to say I don't know it

    I've made a small program that allocates a 64,000 byte buffer, reads data from a file into it and then opens another file and writes it. However, after compiling it in Turbo C++ 3.0 and then running it, Windows catches a general protection fault (a crash in real DOS). The problem is, I'm not sure why...
    Here's the code:-
    Code:
    #include <stdio.h>
    
    int main(void)
    {
       FILE *fp;
       unsigned char *screen;
    
       fp = fopen("image", "rb");
       screen = (unsigned char *)malloc(64000);
       fread(screen, 64000, 1, fp);
       fclose(fp);
       fp = fopen("data.raw", "wb");
       fwrite(screen, 64000, 1, fp);
       fclose(fp);
       return(0);
    }
    The actual program won't always allocate 64,000 bytes each time, so a static buffer isn't the answer. I have a feeling I'm misusing pointers here. Any ideas?

  2. #2
    C > C++ duders ggs's Avatar
    Join Date
    Aug 2001
    Posts
    435
    You should free the memory once the program is done; that might be causing the crash..

    You might also like to check for errors as well in the program...

    ie after each fopen check if fp == NULL (didn't open the files..) or see if screen == NULL after the malloc (who knows, maybe your computer doesn't have 64000 bytes to allocate ).

    Failing at that, pepper your code with printfs after each major statement (in this case, all of them) and fflush(stdout) after each printf. This way you'll see when the code stops and which statement it's crashing on. This technique works for just about anything...
    .sect signature

  3. #3
    ATH0 quzah's Avatar
    Join Date
    Oct 2001
    Posts
    14,826
    > You should free the memory once the program is done; that
    > might be causing the crash..

    Memory should automaticly be freed by the actual termination of the program, but yeah, freeing when you're done is always a good thing to do anyway.

    1) Test to make sure you're actually opening a file. fp could be NULL.
    2) Test malloc's return value for NULL.
    3) Test to make sure your second file opens correctly also.

    These would be good things to try. Additionally, you could write some debug lines in there, to see how far it gets.

    #define mydebug(x) puts( (x) ); fflush( stdout )

    Then call it like: mydebug( "Malloc worked." );

    However, I think it is possible that your real problem is your compiler. TC++ 3.0 is an old DOS based compiler. As such, your integer is only 16 bits. If you are not using an unsigned value, well, there's your problem. I believe all of the functions you're using take an integer as an argument. As such, you end up passing a negative value to them due to the sign bit/overflow.


    Quzah.

  4. #4
    Registered User
    Join Date
    Sep 2001
    Posts
    752
    If your compiler is old, then it may be running into trouble with allocating that much memory. It is not unlikely that you'll end up with screen == NULL every time. If that is the case, I suggest getting a 32-bit compiler, like DJGPP (check the www.cprogramming.com mainpage).

    And the file functions use unsigned int, not int, so they should be large enough for these purposes.
    Last edited by QuestionC; 10-22-2001 at 07:24 PM.

  5. #5
    Registered User
    Join Date
    Sep 2001
    Posts
    412
    You're programming true DOS. You most likely no longer have any conventional memory free, or not the ~ 64k you ask for.

    You need to:

    1) Port it to a windows console program,
    2) Use a DOS extender to use protected mode and thus be able to access more memory.

  6. #6
    Registered /usr
    Join Date
    Aug 2001
    Location
    Newport, South Wales, UK
    Posts
    1,273
    Well, you were right, it is malloc() that is causing the problem (returns NULL). I even tried compiling in the large memory model, it allocates the memory, but then crashes on the fread statement big-time ("Windows protection error. You must restart your computer. Please stow your tray in the upright position and prepare to die, etc.").
    Thing is, I'm almost certain I could get Turbo C 2.0 to allocate the memory without any problem... oh well :[

  7. #7
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    > However, after compiling it in Turbo C++ 3.0 and then running it
    Check which memory model you compiled with - if it's small / tiny / compact?, then you've got a max possible allocation (for all your data) of 64K.

    I've also heard that a program running within the IDE has a lot less memory to play with than a normal .exe would have.

    > screen = (unsigned char *)malloc(64000);
    There is no prototype for malloc in scope, so who know's how that 64000 is being mangled by 16 bit arithmetic.

    Is there some smaller value for memory size (say 20000) which works (for testing etc).
    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.

  8. #8
    Registered /usr
    Join Date
    Aug 2001
    Location
    Newport, South Wales, UK
    Posts
    1,273
    Grrr, I've modified the code a bit (so fread and fwrite's first parameters are &screen instead of screen), and the code runs all the way to the return statement before stopping. Lemme outta this execution thread!!! :P

  9. #9
    Registered User
    Join Date
    Sep 2001
    Posts
    412
    But &screen is WRONG. This will copy data to the location of the pointer, instead of the location that the pointer points at.

    Try switching the 1 and the 64000 in your fread/fwrite calls. This means it reads or writes up to 64,000 elements, each size 1 byte, instead of reading/writing up to one element of 64,000 bytes.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Using pointers to pointers
    By steve1_rm in forum C Programming
    Replies: 18
    Last Post: 05-29-2008, 05:59 AM
  2. Replies: 4
    Last Post: 12-10-2006, 07:08 PM
  3. Request for comments
    By Prelude in forum A Brief History of Cprogramming.com
    Replies: 15
    Last Post: 01-02-2004, 10:33 AM
  4. Staticly Bound Member Function Pointers
    By Polymorphic OOP in forum C++ Programming
    Replies: 29
    Last Post: 11-28-2002, 01:18 PM