Know a way to increase the size of the Input Buffer?

[defrancis7]

I am a hobbiest programmer, (meaning that I program more or less for the fun of it), and am trying to learn how to program using the Windows API.  I had the local library borrow Charles Petzold's "Windows Programming:  Fifth Edition" from a nearby university.  I realize that the book is 14 years old and that there may be better ways code, but, you have to start somewhere.  Petzold is still highly recommended. The book came without its CD, so, I have to type in by hand each of the programs.  No big deal, learning by doing is usually the best teacher in my experience.  (I have also downloaded the SDK for Win 7 from the MicroSoft website for a reference.)

Anyway, I spent about 10 hours typing in the code for a series of .c, .rc, and .h listings that are used to compile and link to a single executable.  (For those curious:  It is the DIBBLE program in the Palette Manager chapter, pages 919 through 994.)  I am using Pelles C, version 6.00, 64-bit, I downloaded last November.  (I thought it was the newer 6.5 version; but, the IDE says it is version 6.)  My system is 64-bit Windows 7.  I compile the project for a WIN32 exe file (not Console).  I get only one error message: C:\<FullPathName>\Dibble.c(234): fatal error #1043: Input Buffer Overflow.

I look at line 234.  It is a macro.  I find it in the relevant .h file and compare it to what is in the book.  As far as I can determine it matches.  I notice that this macro is composed of another previously defined macro.  I check out the previously defined macro and my code listing matches the book.  This leads to yet another macro; but, the point here is that I have looked at all my code listings comparing them to the book and found no difference.

I know that an Input Buffer Overflow means that the calling program tried load more data into its buffer than the buffer can hold.  My question is which program:  the one that I am trying to build or the compiler?  I tried to find some reference to setting the size of the buffer that the compiler uses in the help section on my hard drive.  (I do not have a home internet connection.  I must the the library's when it is open.)  I did find sections about setting and using a buffer for data I/O from my program; but nothing about how I might increase the size of the compiler's buffer.  I am thinking that since Petzold defined so many macro and forward function references that the compiler ran out of memory.  Is this a reasonable deduction?  If so, is there a way to increase the buffer size of compiler?  If not, could I get around the problem by rewriting the code expanding the macros?

I am sorry that I have made such a long post to ask a simple question.  I just wanted to be as clear as possible.  I am annoyed that I have spent so many hours typing in the listing and being stopped from running the program by one error; which I can not seem to find any reference to in the compiler help file.  I'll check back here Friday morning (GMT - 5 hours) for any responses.  Thank you.

Dee

[Bitbeisser]

First of all, I would recommend that you actually upgrade your Pelle's C, 6.00 is a bit old now that 7.0 is just out. It will tell you the exact version both when you start the IDE in the splash screen or in the Help->About Pelle's C screen...

Beside that, to have any idea what your actual problem is, please zip up the files for your lottle project (.c, h, and .ppj) and attach it to a post here in the forum. Then anyone actually has a chance to take a look and help you out, not everyone might simply have a copy of that book to know what exact code you're talking about...

Ralf

[aardvajk]

The book came without its CD, so, I have to type in by hand each of the programs.

You could have googled and found his website. It contains links to download the source code files, and indeed the whole CD. I won't argue with the learning by doing approach, but typing it all out is a bit extreme.

[CommonTater]

I get only one error message: C:\<FullPathName>\Dibble.c(234): fatal error #1043: Input Buffer Overflow.

Indeed typing this stuff up is a bit of work, but I guess we're alike in that a lesson stays with me better when I have to work for it. 

First take Ralf's advice and use the Project -> zip files option and post the zip here.

That is a compile time error so it's the compiler's imput buffer that's overflowing, not your program's ....  My best guess would be to look for silly things like missing blank lines at the ends of your source files, missing semi-colons, mismatched braces, stuff like that... That it's pointing at a macro most likely means the error began sometime before that line but exactly where is impossible to tell without seeing your source code.

[defrancis7]

Took a quick look back here before leaving the library today.  A big Thank you to all that posted a reply.  I'll try answer some of the questions you posted

I downloaded the new Version 7.0 package this morning.  I will uninstall my version 6.0 and install the new version when I get home later tonight.  I'll save all my files first so I don't loose anything though.

I thought about zipping up the program files that gave me the problem and posting them here; but, I was little concerned about posting copyrighted material without authorization.  I will look over the code listings again, line by line, and see if what I have got matches the book.  I knew about the author's website; but, I think I learn something better when I actually do it.  (Like I did with TurboC 3.1.  I got  a couple of books, read the material, typed out the listings, and test the resulting programs.  Then, I converted some the old BASIC programs I had written to C/C++.)

Thanks to you all,
Dee

[defrancis7]

Thanks again to all who responded.  I successfully installed version 7.  It seems as easy to use as version 6.

I went over the code listings in the book; comparing them to what I had typed.  The major differences between the book's and my listings are the expansions of the for and if statements.  When the if, or for, performs a single action, i.e. like return from a function if a condition is met, he did not enclose the return statement in braces.  I like to enclose the action statement in braces.  Of course, when a met condition had two or more, Petzold did use braces.

As for as how I precede, I have the book for another two weeks.  (I renewed for the second time today.)  I'm making myself a note and going further into the material.  I'll come back to this problem when I have more time.

As for my question, I must assume that there is no way to adjust the buffer size(s)  that the compiler / linker use.

Dee

[czerny]

The buffer is big enough.

If you have forgotten a quotationmark or something similar, than the buffer had to be infinity.
It is better to search for your error.

Try to comment a large portion of your code out. If the code compiles than you have the error in the commented part. Try to decrease the commented part step by step and you will find your problem.

czerny

[CommonTater]

When the if, or for, performs a single action, i.e. like return from a function if a condition is met, he did not enclose the return statement in braces.  I like to enclose the action statement in braces.  Of course, when a met condition had two or more, Petzold did use braces.

Usually it makes no difference with a single statement such as...

Code: [Select]

if (x == 10)
  return;
However; C's scoping rules are such that the beginning curley brace marks the start of a scope and, of course, the matching end brace ends the scope.  This can be used to advantage in that you can define localized variables in each scope...

Code: [Select]

if (x == 10)
  { int y;
     y = x + 37;
     return y; }
... that will be invisible outside that scope. 

You can also define scopes with braces in straight line code...

Code: [Select]

{
   int y;
   y = x + 37;
 }
... which effectively hides y from your mainline code.

While this can be very useful, it can also lead to problems such as localized variables overlaying mainline variables, magic numbers or variables you can't access... so use it with caution.

As a general rule it's best to use things in C "as necessary" rather than out of mere habit.

[defrancis7]

Good ideas,  czerny and Common Tater.  I'll definitely look at the placement of quote marks and parenthesis in the listings.  Part of the reason I wanted to move on to further topics is because I will have the book only for a week and a half.  I definitely want to go through the offending program while I still have the book.  I have noticed that because of reading the book that I can follow the material in the SDK more easily.

I expanded the 'if', 'for', and similar statements because of code readability.  It helps me understand what is going on in the program when the scope of a function/statement is clearly obvious.  I never know when I am going to go back at a much later date and adapt a piece of code to make the program do one thing more.   The program in the book that prompted my question, "Dibble.c", has a little over 2,000 lines of code (including the shell programs and resources).  Some places in the listing(s) have nested ifs (and fors).  In a written book, when you turn a page and at the top of the page see an 'else', to which 'if' does the else clause apply?  (Most are obvious though.)  Comments help but can clutter-up the listing as you go into more and more specific details about what the function/statement is trying to accomplish.

(I am one of those guys that when texting will type "See you later" instead of "C U L8R.") 
Dee

[CommonTater]

Me?  I comment the heck out of everything... as you say there's no way to know when you might have to come back to your code --perhaps years later-- and still follow it.  So I mark every variable and function with what it does and will intersperse comments inside functions for the non-obvious stuff like this...

Code: [Select]

// open and translate file
BOOL M3ULaunch(PWCHAR FileName)
  { PBYTE  rf;      // raw file data
    DWORD  br;      // bytes read
    // load the raw file
    { HANDLE pl;    // playlist file handle
      DWORD  fs;    // file size
      // get path to file
      wcsncpy(FilePath,FileName,MAX_PATH);
      PathRemoveFileSpec(FilePath);
      wcscat(FilePath,L"\\");
      // open the file
      pl = CreateFile (FileName,GENERIC_READ,0,NULL,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,NULL);
      if (pl == INVALID_HANDLE_VALUE)
        Exception(GetLastError());
      fs = GetFileSize(pl,NULL);       
      rf = calloc(fs + 2, sizeof(BYTE));
      if (! ReadFile(pl, rf, fs, &br, NULL))
        Exception(GetLastError());
      CloseHandle(pl); 
      if (br != fs)
        Exception(0xE00640007); }
    try                                   
     { DWORD bom = *(DWORD*)rf;
       if ((bom == 0x0000FEFF) || (bom == 0xFFFE0000))  // utf32le bom 
         Exception(0xE0640002);                         // utf32be bom 
       else if ((bom & 0xFFFF) == 0xFFFE)               // utf16be bom
         { FlipEndian(rf,br);
           CopyWChar((PWCHAR) rf + 1); }
       else if ((bom & 0xFFFF) == 0xFEFF)               // utf16le bom
         CopyWChar((PWCHAR) rf + 1); 
       else if ((bom & 0xFFFFFF) == 0xBFBBEF)           // utf8 bom
         CopyMByte(rf + 3, br - 3);
       else                                             // no known bom, probe the file
         { if (! memchr(rf, 0x00, br))                  // 8 bit text has no nulls
             CopyMByte(rf,br);                          // ansi / utf8 no bom
           else
            { PBYTE lf = memchr(rf,0x0A,br);            // lf is always present as 1 byte.
              if (!lf)
                Exception(0xE0640003);
              if ((!(*(DWORD*)(lf - 3) & 0x00FFFFFF)) ||    //utf32be no bom
                   (!(*(DWORD*)lf & 0xFFFFFF00)))           //utf32le no bom
                 Exception(0xE0640002);   
              if ((lf - rf) & 1)                        // big endian? (lf at odd offset)
                FlipEndian(rf,br);                      // utf16be no bom 
              CopyWChar((PWCHAR) rf);  } } }            // utf16le no bom
     finally 
      { free(rf); }
    return 1; }
... also note that I am using inline scopes in this particular function as well.  If I didn't comment that, in three years it's going to look like Klingon secret code to me.
 
For the matter of only having the book for a short while...
A) You can probably order your own copy from Amazon
B) There are lots and lots of free online resources for both C and Windows API
... Google is your friend