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?

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...

> 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.

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.

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.

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 :[

> 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).

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

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.