Thread: Using malloc

  1. #1
    Math wizard
    Join Date
    Dec 2006
    Location
    USA
    Posts
    582

    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.
    High elevation is the best elevation. The higher, the better the view!
    My computer: XP Pro SP3, 3.4 GHz i7-2600K CPU (OC'd to 4 GHz), 4 GB DDR3 RAM, X-Fi Platinum sound, GeForce 460, 1920x1440 resolution, 1250 GB HDD space, Visual C++ 2008 Express

  2. #2
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    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.

  3. #3
    Math wizard
    Join Date
    Dec 2006
    Location
    USA
    Posts
    582
    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.
    High elevation is the best elevation. The higher, the better the view!
    My computer: XP Pro SP3, 3.4 GHz i7-2600K CPU (OC'd to 4 GHz), 4 GB DDR3 RAM, X-Fi Platinum sound, GeForce 460, 1920x1440 resolution, 1250 GB HDD space, Visual C++ 2008 Express

  4. #4
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    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.

  5. #5
    Math wizard
    Join Date
    Dec 2006
    Location
    USA
    Posts
    582
    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.
    High elevation is the best elevation. The higher, the better the view!
    My computer: XP Pro SP3, 3.4 GHz i7-2600K CPU (OC'd to 4 GHz), 4 GB DDR3 RAM, X-Fi Platinum sound, GeForce 460, 1920x1440 resolution, 1250 GB HDD space, Visual C++ 2008 Express

  6. #6
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    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.

  7. #7
    Math wizard
    Join Date
    Dec 2006
    Location
    USA
    Posts
    582
    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.
    Last edited by ulillillia; 02-18-2008 at 05:17 PM. Reason: Strange error occurring
    High elevation is the best elevation. The higher, the better the view!
    My computer: XP Pro SP3, 3.4 GHz i7-2600K CPU (OC'd to 4 GHz), 4 GB DDR3 RAM, X-Fi Platinum sound, GeForce 460, 1920x1440 resolution, 1250 GB HDD space, Visual C++ 2008 Express

  8. #8
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    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.

  9. #9
    Math wizard
    Join Date
    Dec 2006
    Location
    USA
    Posts
    582
    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.
    Last edited by ulillillia; 02-18-2008 at 05:38 PM. Reason: Mentioned the warning and a side note
    High elevation is the best elevation. The higher, the better the view!
    My computer: XP Pro SP3, 3.4 GHz i7-2600K CPU (OC'd to 4 GHz), 4 GB DDR3 RAM, X-Fi Platinum sound, GeForce 460, 1920x1440 resolution, 1250 GB HDD space, Visual C++ 2008 Express

  10. #10
    Math wizard
    Join Date
    Dec 2006
    Location
    USA
    Posts
    582
    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?
    High elevation is the best elevation. The higher, the better the view!
    My computer: XP Pro SP3, 3.4 GHz i7-2600K CPU (OC'd to 4 GHz), 4 GB DDR3 RAM, X-Fi Platinum sound, GeForce 460, 1920x1440 resolution, 1250 GB HDD space, Visual C++ 2008 Express

  11. #11
    Just Lurking Dave_Sinkula's Avatar
    Join Date
    Oct 2002
    Posts
    5,005
    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.
    7. It is easier to write an incorrect program than understand a correct one.
    40. There are two ways to write error-free programs; only the third one works.*

  12. #12
    Hurry Slowly vart's Avatar
    Join Date
    Oct 2006
    Location
    Rishon LeZion, Israel
    Posts
    6,788
    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)
    All problems in computer science can be solved by another level of indirection,
    except for the problem of too many layers of indirection.
    – David J. Wheeler

  13. #13
    Math wizard
    Join Date
    Dec 2006
    Location
    USA
    Posts
    582
    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.
    High elevation is the best elevation. The higher, the better the view!
    My computer: XP Pro SP3, 3.4 GHz i7-2600K CPU (OC'd to 4 GHz), 4 GB DDR3 RAM, X-Fi Platinum sound, GeForce 460, 1920x1440 resolution, 1250 GB HDD space, Visual C++ 2008 Express

  14. #14
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    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;
    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.

  15. #15
    Math wizard
    Join Date
    Dec 2006
    Location
    USA
    Posts
    582
    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.
    Last edited by Dave_Sinkula; 02-20-2008 at 02:41 PM. Reason: More width tinkering.
    High elevation is the best elevation. The higher, the better the view!
    My computer: XP Pro SP3, 3.4 GHz i7-2600K CPU (OC'd to 4 GHz), 4 GB DDR3 RAM, X-Fi Platinum sound, GeForce 460, 1920x1440 resolution, 1250 GB HDD space, Visual C++ 2008 Express

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. malloc + segmentation fault
    By ch4 in forum C Programming
    Replies: 5
    Last Post: 04-07-2009, 03:46 PM
  2. the basics of malloc
    By nakedBallerina in forum C Programming
    Replies: 21
    Last Post: 05-20-2008, 02:32 AM
  3. Is there a limit on the number of malloc calls ?
    By krissy in forum Windows Programming
    Replies: 3
    Last Post: 03-19-2006, 12:26 PM
  4. Malloc and calloc problem!!
    By xxhimanshu in forum C Programming
    Replies: 19
    Last Post: 08-10-2005, 05:37 AM
  5. malloc() & address allocation
    By santechz in forum C Programming
    Replies: 6
    Last Post: 03-21-2005, 09:08 AM