Using malloc

Having only recently heard of the "malloc" function, supposedly to dynamically change the size of an array, I wanted to adjust my "LoadFile" function to using it, if it does what I think it does. I don't know how to set up the function parameters mainly. Here's the related code I have:

Code:

// the global variable declarations (array sizes given is what should be allocated)

...
unsigned char PrelakeHills04Data[700416]; // The prelake hills layer 4 background
unsigned char *PrelakeHills04MainDataPointer; // malloc requires a pointer to the data
unsigned long PrelakeHills04MemoryUsage;
LPVOID PrelakeHills04DataPointer; // data pointer for use in AlphaBlend and DrawDibDraw functions
BITMAPINFO PrelakeHills04MainInfo;
BITMAPINFOHEADER PrelakeHills04Info;
LPBITMAPINFOHEADER PrelakeHills04InfoPointer;
HBITMAP PrelakeHills04BMPHandle;
struct SceneryData PrelakeHills04;
unsigned char PrelakeHills03Data[343040]; // The prelake hills layer 3 background
unsigned char *PrelakeHills03MainDataPointer;
unsigned long PrelakeHills03MemoryUsage;
LPVOID PrelakeHills03DataPointer;
BITMAPINFO PrelakeHills03MainInfo;
BITMAPINFOHEADER PrelakeHills03Info;
LPBITMAPINFOHEADER PrelakeHills03InfoPointer;
HBITMAP PrelakeHills03BMPHandle;
struct SceneryData PrelakeHills03;
unsigned char PrelakeHills02Data[106496]; // The prelake hills layer 2 background
unsigned char *PrelakeHills02MainDataPointer;
unsigned long PrelakeHills02MemoryUsage;
...

// the function's header (yes, lots of parameters)

char LoadFile(const char FileName[64], char FileType, BITMAPINFOHEADER *BMPInfo, unsigned char *BMPData, char FogUsed, double ObjectScaling, char LoadType, unsigned char *BMPDataPointer, unsigned long *BMPMemoryUsage)
{
	// local variables, setting directories, and setting the file handle (no problems here)
	...

			// filling the structure works fine
			fseek(FileHandle, 14, SEEK_SET); // skip the basic file header data but read from the info header
			fread(&ValuesBase, 1, 4, FileHandle); // bytes 0E through 11
			BMPInfo->biSize = (DWORD)ValuesBase[0]+(DWORD)ValuesBase[1]*256+(DWORD)ValuesBase[2]*65536+(DWORD)ValuesBase[3]*16777216;
			fread(&ValuesBase, 1, 4, FileHandle); // bytes 12 through 15
			BMPInfo->biWidth = (long)ValuesBase[0]+(long)ValuesBase[1]*256+(long)ValuesBase[2]*65536+(long)ValuesBase[3]*16777216;
			fread(&ValuesBase, 1, 4, FileHandle); // bytes 16 through 19
			BMPInfo->biHeight = (long)ValuesBase[0]+(long)ValuesBase[1]*256+(long)ValuesBase[2]*65536+(long)ValuesBase[3]*16777216;
			fread(&ValuesBase, 1, 2, FileHandle); // bytes 1A and 1B
			BMPInfo->biPlanes = (WORD)ValuesBase[0]+(WORD)ValuesBase[1]*256;
			fread(&ValuesBase, 1, 2, FileHandle); // bytes 1C and 1D
			BMPInfo->biBitCount = (WORD)ValuesBase[0]+(WORD)ValuesBase[1]*256;
			fread(&ValuesBase, 1, 4, FileHandle); // bytes 1E through 21
			BMPInfo->biCompression = (DWORD)ValuesBase[0]+(DWORD)ValuesBase[1]*256+(DWORD)ValuesBase[2]*65536+(DWORD)ValuesBase[3]*16777216;
			fread(&ValuesBase, 1, 4, FileHandle); // bytes 22 through 25
			BMPInfo->biSizeImage = (DWORD)ValuesBase[0]+(DWORD)ValuesBase[1]*256+(DWORD)ValuesBase[2]*65536+(DWORD)ValuesBase[3]*16777216;
			fread(&ValuesBase, 1, 4, FileHandle); // bytes 26 through 29
			BMPInfo->biXPelsPerMeter = (long)ValuesBase[0]+(long)ValuesBase[1]*256+(long)ValuesBase[2]*65536+(long)ValuesBase[3]*16777216;
			fread(&ValuesBase, 1, 4, FileHandle); // bytes 2A through 2D
			BMPInfo->biYPelsPerMeter = (long)ValuesBase[0]+(long)ValuesBase[1]*256+(long)ValuesBase[2]*65536+(long)ValuesBase[3]*16777216;
			fread(&ValuesBase, 1, 4, FileHandle); // bytes 2E through 31
			BMPInfo->biClrUsed = (DWORD)ValuesBase[0]+(DWORD)ValuesBase[1]*256+(DWORD)ValuesBase[2]*65536+(DWORD)ValuesBase[3]*16777216;
			fread(&ValuesBase, 1, 4, FileHandle); // bytes 32 through 35
			BMPInfo->biClrImportant = (DWORD)ValuesBase[0]+(DWORD)ValuesBase[1]*256+(DWORD)ValuesBase[2]*65536+(DWORD)ValuesBase[3]*16777216;
			
			BMPMemoryUsage = BMPInfo->biWidth*BMPInfo->biHeight*3; // determine the amount of memory usage - 24-bit BMP's use 3 bytes per pixel
			BMPDataPointer = malloc(BMPMemoryUsage); // allocate the memory for the amount given in the previous statement
			fread(BMPData, 1, BMPMemoryUsage, FileHandle); // read the main image data // reads in BGR format
			...
			
	// rest of function, which works without problems
}

...
// at end of main function
	free(PrelakeHills04MainDataPointer); // release the memory, to avoid memory leaks

What I want to do is call the function like this:

Code:

LoadFile("PrelakeHills04.tga", 2, &PrelakeHills04Info, PrelakeHills04Data, 1, PrelakeHills04.Scaling, 0, PrelakeHills04MainDataPointer, PrelakeHills04MemoryUsage);

I don't know how to set up the function so that it reads the amount of data allocated in the main data array, no more, no less.

I think you need to go about it the other way around: Figure our how much data LoadFile() gives, and make sure that you have a large enough storage for that.

Or have I misunderstood what you want to do?

--
Mats

What is supposed to happen is that, I first read the file info header, for the width and height primarily. With this put into the BITMAPINFOHEADER structure, of which works like it's supposed to, I can calculate how much memory the image data itself would take, which is simply "Width*Height*BitDepth/8". For a 24-bit BMP file of a 1024x32-pixel size, I would need to allocate 1024*32*3 or 98,304 bytes of memory. The image data array needs to be resized and which one it is (since I'll be having well over 300) is set when the function is called.

The 2 problems that I have is that I'm not sure I'm using malloc properly and second, I'm not sure how to set up the function parameters. With over 300 separate images (could potentially reach even 500, though I don't know for sure), having a single function dedicated to reading from files to fill in structures, set pointers, etc. is very convienient over having the same pieces of code repeating 300+ times taking up over 20,000 lines of code in just file loading and image preparation alone.

OK, so have you checked that BMPMemoryUsage is the correct value compared to what you expect?

Then confirm that your fread() call reads the same amount of data in.

The call to malloc itself looks right.

What also strikes me is that you are reading a lot of data values as 4 bytes, then merge those four bytes into an integer value. Perhaps writing one function that does that work would be more efficient, so that each of these:

Code:

			fread(&ValuesBase, 1, 4, FileHandle); // bytes 0E through 11
			BMPInfo->biSize = (DWORD)ValuesBase[0]+(DWORD)ValuesBase[1]*256+
                                       (DWORD)ValuesBase[2]*65536+(DWORD)ValuesBase[3]*16777216;

becomes a single, short line.

Obviously, the 16-bit values need a separate function.


--
Mats

I have it read this way to work around endianness. If I went with 4 then 1 to read a single value 4 bytes long, the endianness of different CPU's can cause different values to be read. That is, if the number 0x20000008 was read this way in little endian, it'd read as 0x80000020 in big endian. I was told this on these forums. I haven't checked whether or not it works yet, but I wanted to make sure I was doing it right. One big question mark is that I seem to have two pointers to the same thing. The LPVOID one, part of the windows.h include, and now my "unsigned char *" one. The other is that I don't know what I need in the fread function.

Yes, reading the bytes in the right order is important, and I'm not saying you shouldn't do that. What I am trying to say is that:

Code:

    x = readDWORD(FileHandle);

is much easier to read and to understand what it does, than two lines that read some 4 bytes and then place the 4 bytes in the correct order into that dword.

So, making a small function (which the compiler will most likely inline anyways, if you are worried about performance - but you shouldn't worry about that here, as reading the little bits of file isn't likely to be where you spend most time resizing an image).

Another thought: If you are using LOTS of parameters to a function, it is often easier to use a struct to pass the arguments all at once. It saves stack-space, and makes the code easier to read, as:

Code:

struct blah
{
   int x, y;
   bool flag;
   char *name;
   float f1, f2, f3;
};

void func(struct blah *b)
{
   ... Do some work with blah... 
}

void callfunc(void)
{
   struct blah b;

   b.x = 1;
   b.y = 1;
   b.flag = false;
   b.name = "Somename";
   b.f1 = 1.2;
   b.f2 = 1.4;
   b.f3 = 1.8;

   func(&b);
}

is easier to follow than:

Code:

void func(struct blah *b)
{
   ... Do some work with blah... 
}

void callfunc(void)
{
   struct blah b;

   func(1, 1, false, "Somename", 1.2, 1.4, 1.8);
}

Especially if you have many arguments with the same type (such as pointers to char or integers).

--
Mats

I compiled the program but I get strange warnings, particularly in a Windows include that make no sense. I've never even seen the code for these, let alone modify it to cause warnings. These are the warnings I'm getting, the first ones that appear:

Code:

c:\program files\microsoft visual studio 8\vc\platformsdk\include\mmsystem.h(1837) : warning C4201: nonstandard extension used : nameless struct/union
c:\program files\microsoft visual studio 8\vc\platformsdk\include\mmsystem.h(1841) : warning C4201: nonstandard extension used : nameless struct/union
c:\program files\microsoft visual studio 8\vc\platformsdk\include\mmsystem.h(1862) : warning C4201: nonstandard extension used : nameless struct/union
c:\program files\microsoft visual studio 8\vc\platformsdk\include\mmsystem.h(1866) : warning C4201: nonstandard extension used : nameless struct/union
c:\program files\microsoft visual studio 8\vc\platformsdk\include\mmsystem.h(2007) : warning C4201: nonstandard extension used : nameless struct/union
c:\program files\microsoft visual studio 8\vc\platformsdk\include\mmsystem.h(2018) : warning C4201: nonstandard extension used : nameless struct/union
c:\program files\microsoft visual studio 8\vc\platformsdk\include\mmsystem.h(2079) : warning C4201: nonstandard extension used : nameless struct/union

The others don't make sense. I know what they mean, but the warnings seem like false positives. I have something like "variable = example;", both as signed shorts, but the warning is stating of a conversion from int to short and a possible loss of data, even though no ints are used in this statement at all. I've got several of these, some expected and fixed, but these other ones make no sense at all and seem like false positives.

I have another question related to malloc/free - how can I check to see if there is a memory leak?

Edit: When I ran my program, I got a very strange error upon first loading the program. I took a screenshot of it here. Previously, I wasn't getting this error, but all of a sudden, it just occurred out of nowhere and fclose.c - that's supposedly a fundamental C-based function which is very strange as I've never viewed nor edited it.

I'm sorry, I can't help on the error messages in mmsystem.h - that's a system include file, and one would THINK that they don't give warnings, but perhaps they are bending the rules a bit.

As for your "possibly lost data", perhaps you can post some code?

--
Mats

The mmsystem.h is supposedly for my timer, of which was working fine just recently. I checked, about 6 hours ago, my previous project and it worked fine, no errors and just 2 warnings and, currently, is very similar to my main one. As to the fclose.c function acting up all of a sudden (see my edit for a link to a screenshot of it), of which worked fine when I had 4 of the hills (for testing, first with 1), and now the only difference is that that I have 20 hills and I'm using malloc to change the size of arrays instead.

Code:

void DrawBMPFont(parameters)
{
	short PosX = 0; // initialize start positions
	short PosY = 0;
	short VSpacing = (short)FontInfo.biHeight; // the vertical spacing
	... // other local variables and other stuff in the function unrelated to the concern

	PosY += VSpacing; // go down a row // conversion from int to short!?  False positive!
}

Edit: The warning is this, if that helps (there are many other similar ones as well, but this is what is focused above, one of the "false positives"):

c:\my documents\my programs\supernatural olympics\supernatural olympics\supernatural olympics.c(1617) : warning C4244: '+=' : conversion from 'int' to 'short', possible loss of data. The other 16 layers of those hills are mostly just copy/paste from previously working ones with small changes in names being made.

Does anyone have any idea what this strange error is that I get upon running my program or how the warnings in mmsystem.h get fixed?

It appears that you have tripped a debugging assertion, one in which you need a non-null pointer to some function you are calling, but instead you are passing a null pointer. Double check your error checking.

compiling with VS2005 I do not get any warnings with mmsystem.h
after passing header in the following order (I have Win SDK installed)

Code:

#include <windows.h>
#include <mmsystem.h>

But if you want to disable one specific warning in one specific header you could do the following:

Code:

#pragma warning(disable:4201)
#include <mmsystem.h>
#pragma warning(default:4201)

Apparently, it seems like windows.h includes mmsystem.h with it. It seems as if the compiler itself has gone haywire or something. This is my build log showing the many warnings I get (those due to using fopen, sprintf, etc. have been removed, others are illogical and should not be occurring (the conversion from int to short even though only signed shorts are used in the entire formula (no constants either, ruling that out) one of the illogical warnings), some were present in previous builds, and I've manually added in the notes:

Code:

------ Build started: Project: Supernatural Olympics, Configuration: Debug Win32 ------
Compiling...
Supernatural Olympics.c
c:\program files\microsoft visual studio 8\vc\platformsdk\include\mmsystem.h(1837) : warning C4201: nonstandard extension used : nameless struct/union
c:\program files\microsoft visual studio 8\vc\platformsdk\include\mmsystem.h(1841) : warning C4201: nonstandard extension used : nameless struct/union
c:\program files\microsoft visual studio 8\vc\platformsdk\include\mmsystem.h(1862) : warning C4201: nonstandard extension used : nameless struct/union
c:\program files\microsoft visual studio 8\vc\platformsdk\include\mmsystem.h(1866) : warning C4201: nonstandard extension used : nameless struct/union
c:\program files\microsoft visual studio 8\vc\platformsdk\include\mmsystem.h(2007) : warning C4201: nonstandard extension used : nameless struct/union
c:\program files\microsoft visual studio 8\vc\platformsdk\include\mmsystem.h(2018) : warning C4201: nonstandard extension used : nameless struct/union
c:\program files\microsoft visual studio 8\vc\platformsdk\include\mmsystem.h(2079) : warning C4201: nonstandard extension used : nameless struct/union

Note 1

c:\my documents\my programs\supernatural olympics\supernatural olympics\keyincludes.h(5) : warning C4005: 'KeyPressed' : macro redefinition
        c:\my documents\my programs\supernatural olympics\supernatural olympics\keyincludes.h(4) : see previous definition of 'KeyPressed'

Note 2

c:\my documents\my programs\supernatural olympics\supernatural olympics\supernatural olympics.c(1588) : warning C4244: '+=' : conversion from 'int' to 'short', possible loss of data
c:\my documents\my programs\supernatural olympics\supernatural olympics\supernatural olympics.c(1592) : warning C4244: '+=' : conversion from 'int' to 'short', possible loss of data
c:\my documents\my programs\supernatural olympics\supernatural olympics\supernatural olympics.c(1617) : warning C4244: '+=' : conversion from 'int' to 'short', possible loss of data
c:\my documents\my programs\supernatural olympics\supernatural olympics\supernatural olympics.c(1638) : warning C4244: '+=' : conversion from 'int' to 'short', possible loss of data
c:\my documents\my programs\supernatural olympics\supernatural olympics\supernatural olympics.c(1644) : warning C4244: '+=' : conversion from 'int' to 'short', possible loss of data
c:\my documents\my programs\supernatural olympics\supernatural olympics\supernatural olympics.c(1673) : warning C4244: '+=' : conversion from 'int' to 'short', possible loss of data

Note 3

c:\my documents\my programs\supernatural olympics\supernatural olympics\supernatural olympics.c(1557) : warning C4189: 'SourceXWidth' : local variable is initialized but not referenced

Note 4

c:\my documents\my programs\supernatural olympics\supernatural olympics\supernatural olympics.c(2717) : warning C4244: '=' : conversion from 'int' to 'short', possible loss of data
c:\my documents\my programs\supernatural olympics\supernatural olympics\supernatural olympics.c(2718) : warning C4244: '=' : conversion from 'int' to 'short', possible loss of data
c:\my documents\my programs\supernatural olympics\supernatural olympics\supernatural olympics.c(2719) : warning C4244: '=' : conversion from 'int' to 'short', possible loss of data
c:\my documents\my programs\supernatural olympics\supernatural olympics\supernatural olympics.c(2720) : warning C4244: '=' : conversion from 'int' to 'short', possible loss of data
c:\my documents\my programs\supernatural olympics\supernatural olympics\supernatural olympics.c(2721) : warning C4244: '=' : conversion from 'int' to 'short', possible loss of data

Note 5

c:\my documents\my programs\supernatural olympics\supernatural olympics\supernatural olympics.c(2960) : warning C4244: 'return' : conversion from 'WPARAM' to 'int', possible loss of data

Note 6

c:\my documents\my programs\supernatural olympics\supernatural olympics\supernatural olympics.c(2682) : warning C4100: 'nCmdShow' : unreferenced formal parameter
c:\my documents\my programs\supernatural olympics\supernatural olympics\supernatural olympics.c(2681) : warning C4100: 'lpCmdLine' : unreferenced formal parameter
c:\my documents\my programs\supernatural olympics\supernatural olympics\supernatural olympics.c(2680) : warning C4100: 'hPrevInstance' : unreferenced formal parameter

Note 7

Linking...
Embedding manifest...
Build log was saved at "file://c:\My Documents\My programs\Supernatural Olympics\Supernatural Olympics\Debug\BuildLog.htm"
Supernatural Olympics - 0 error(s), 33 warning(s)
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

Note 1: Suspicious warnings for something I've never touched and was working fine 5 months ago, the last time I was programming windows programs with it.
Note 2: Strangely enough, if the redefinition is left out, GetAsyncKeyState doesn't work properly (it should get checked each frame rather than depend on the repeat rate for the keyboard (which is bad for games), but it does if it is. I was given this code and I just ignored the warning.
Note 3: These are illogical - only shorts are used (a few of them involve a char (from a string), but no ints are involved at all).
Note 4: This is an expected warning on my end and not a fault with the compiler so this isn't a focal point.
Note 5: These are expected - the variable is a short, but the function returns an int.
Note 6: This is semi-expected as I'm not sure how to address this.
Note 7: This is questioned as, earlier, I wasn't getting this warning 5 months ago on my previous build.

As to my program, I moved the windows.h include to being directly below the stdio.h include which is the top include I have. The debugging assertion error went away upon doing so. When I did move it, and test ran my program, I get an "unhandled exception" error, hinting that malloc isn't working properly.

Code:

Note 2

c:\my documents\my programs\supernatural olympics\supernatural olympics\supernatural olympics.c(1588) : warning C4244: '+=' : conversion from 'int' to 'short', possible loss of data
c:\my documents\my programs\supernatural olympics\supernatural olympics\supernatural olympics.c(1592) : warning C4244: '+=' : conversion from 'int' to 'short', possible loss of data
c:\my documents\my programs\supernatural olympics\supernatural olympics\supernatural olympics.c(1617) : warning C4244: '+=' : conversion from 'int' to 'short', possible loss of data
c:\my documents\my programs\supernatural olympics\supernatural olympics\supernatural olympics.c(1638) : warning C4244: '+=' : conversion from 'int' to 'short', possible loss of data
c:\my documents\my programs\supernatural olympics\supernatural olympics\supernatural olympics.c(1644) : warning C4244: '+=' : conversion from 'int' to 'short', possible loss of data
c:\my documents\my programs\supernatural olympics\supernatural olympics\supernatural olympics.c(1673) : warning C4244: '+=' : conversion from 'int' to 'short', possible loss of data

Those could be suppressed with simple casts. Unless you have max warnings, in which case it doesn't like truncating at all. You must use appropriate types or it will warn constantly from my experience. Never found out how to fix that.

Code:

Note 3

c:\my documents\my programs\supernatural olympics\supernatural olympics\supernatural olympics.c(1557) : warning C4189: 'SourceXWidth' : local variable is initialized but not referenced

But this says you have a variable named SourceXWidth which you've initialized, but never used elsewhere in the code. You could remove it.

Code:

Note 4

c:\my documents\my programs\supernatural olympics\supernatural olympics\supernatural olympics.c(2717) : warning C4244: '=' : conversion from 'int' to 'short', possible loss of data
c:\my documents\my programs\supernatural olympics\supernatural olympics\supernatural olympics.c(2718) : warning C4244: '=' : conversion from 'int' to 'short', possible loss of data
c:\my documents\my programs\supernatural olympics\supernatural olympics\supernatural olympics.c(2719) : warning C4244: '=' : conversion from 'int' to 'short', possible loss of data
c:\my documents\my programs\supernatural olympics\supernatural olympics\supernatural olympics.c(2720) : warning C4244: '=' : conversion from 'int' to 'short', possible loss of data
c:\my documents\my programs\supernatural olympics\supernatural olympics\supernatural olympics.c(2721) : warning C4244: '=' : conversion from 'int' to 'short', possible loss of data

Same as note 2.

Code:

Note 5

c:\my documents\my programs\supernatural olympics\supernatural olympics\supernatural olympics.c(2960) : warning C4244: 'return' : conversion from 'WPARAM' to 'int', possible loss of data

A cast should do there, I think.

Code:

Note 6

c:\my documents\my programs\supernatural olympics\supernatural olympics\supernatural olympics.c(2682) : warning C4100: 'nCmdShow' : unreferenced formal parameter
c:\my documents\my programs\supernatural olympics\supernatural olympics\supernatural olympics.c(2681) : warning C4100: 'lpCmdLine' : unreferenced formal parameter
c:\my documents\my programs\supernatural olympics\supernatural olympics\supernatural olympics.c(2680) : warning C4100: 'hPrevInstance' : unreferenced formal parameter

There are usually three ways of solving those.

Either you remove the variable from the argument list of the function.
Or you remove the name of the variable from the definition or implementation:

Code:

void foo(void* myarg1, int myarg2, char myarg3)

Becomes

Code:

void foo(void*, int, char)

Yes, this is the definition or the implementation and not the declaration.

Or you can add the name of the argument and a semicolon after to suppress the warning, like:

myarg1;
myarg2;
myarg3;

You apparently haven't read the whole post, plus, you've referenced the notes incorrectly. Note 2 deals with the macro redefinition. Note 3 is what you first quoted.

For notes 3 and 5, I have no ints used in the line flagged so it shouldn't warn about the conversion from int to short. As to note 4, it's not a focal point so I'm not concerned. I don't want to actually remove it as I may need it in a future edit to that function, but I could, for now, just comment it out. Note 6 deals with a Windows definition. WPARAM is a Windows thing but it, like note 4, is not a focal point. Note 7 deals with the WinMain function, essential to Windows itself so these parameters are needed (as far as I know anyway). They worked without reporting warnings earlier, it just happened all of a sudden, the same with the case for note 1.

What about the case of malloc not working? I have a statement (using a global variable) that tells how much memory is needed. One of the images, the largest known so far is 2048x185 at 32-bit color. Look at the code in the original first post, particularly near the bottom, and you'll see this:

Code:

   // determine the amount of memory usage - 24-bit BMP's use 3 bytes per pixel
   BMPMemoryUsage = BMPInfo->biWidth*BMPInfo->biHeight*3;

   // allocate the memory for the amount given in the previous statement
   BMPDataPointer = malloc(BMPMemoryUsage); 

   // read the main image data // reads in BGR format
   fread(BMPData, 1, BMPMemoryUsage, FileHandle);

This is used with the 24-bit bitmaps. Another one identical to this is used for TGA files which has "*4" at the end. I checked for a possible copy/paste error and I don't see any. Working it out, that 2048x185 image at 32-bit color should use 1,515,520 bytes of memory (slightly less than 1.5 MB). The next thing I do is use malloc to allocate this amount of memory. Following that is reading 1,515,520 bytes from the file which will completely fill the array with nothing wasted or going outside of the array's bounds. With this, going outside of the array's boundaries shouldn't happen, unless the computer made a math error.

Either the pointer setup is bad (I can't check it since I can't run my program to check it (I get the unhandled exception error, typically caused from going outside of the array's boundaries)) or the setup for the function parameters and calling it is done incorrectly. Another possibility is that I'm using malloc incorrectly.