Menu

loop crash

Anonymous
2003-11-16
2012-09-26
  • Anonymous

    Anonymous - 2003-11-16

    i've been having trouble with the loop in this switch case:
                    case ID_BUTTONCODE:
                        file.open("maker.dat",ios::app);
                        x = 0;
                        listCount = SendDlgItemMessage((HWND)hMakerDialog,ID_LISTBOXSTYLES,(UINT)LB_GETCOUNT,0,0) - 1;
                        if(listCount < 0) {
                            break;
                        }
                        SendDlgItemMessage((HWND)hMakerDialog,ID_LISTBOXSTYLES,(UINT)LB_GETTEXT,(WPARAM)x,(LPARAM)buffer);
                        file.write(buffer,sizeof(buffer));
                        x += 1;
                        if(x > listCount) {
                            break;
                        }
                        do {
                            SendDlgItemMessage((HWND)hMakerDialog,ID_LISTBOXSTYLES,(UINT)LB_GETTEXT,(WPARAM)1,(LPARAM)buffer);
                            file.write(strcat(" | ", buffer),sizeof(buffer));
                            x += 1;
                            if(x > listCount) {
                                file.close();
                                file.open("maker.dat",ios::out);
                                file.read(fBuffer,sizeof(fBuffer));
                                if(file.eof()) {
                                    SetDlgItemText((HWND)hMakerDialog,ID_EDITCODE,fBuffer);
                                }
                            }   
                        } while(x <= listCount);
                        file.close();
                        break;

    1) the file maker.dat does not open for appending
    2) the loop crashes the program
    3) there are no errors during compilation

    i think it has to do with the file not closing and the strcat() functions.

    buffer and fBuffer are char*
    x is an integer

     
    • Anonymous

      Anonymous - 2003-11-16

      Posting a short peice of code is usually a good idea, but it is best if it is also complete. The point at which a program crashes is seldom the point at which the error was initiated. And we only have your word for it about the data types (not that I am doubting your word, but the subtleties of the language are such, that pecision is key, and the actual code is the best way of being precise. Consequently I am guessing:

      1)
      Not sure, someone more familiar with iostream may be able to help. Is the file definately in the working directory. Try an explicit fully qualified path to make sure. Try explicitly specifying open for output as well as append: ios::out | ios::app. In any case, use the is_open() member to test is the open was successful before attempting to write.

      2)
      Attempting to write to a file taht has not opened may not be helpful, see (1) above.

      If buffer is a char*, sizeof(buffer) will be the size of the pointer itself (4 bytes), not the size of the array it points to.

      If buffer is actually a char array rather than a char* as you have said, then sizeof(buffer) will be correct.

      However beware, when you pass an array to a function, it is converted to a char*, so sizeof(buffer) will only be correct where the array is in scope.

      In short an array name is not simply a pointer, because the result of sizeof() is different. However, it can explicitly or implicitly be cast to a pointer, and when this happens, the array size information is lost.

      If buffer is a C style NUL terminated string (implied by use of strcat() ), then you can use strlen() to find its length.

      Even is sizeof(buffer) is correct, writing it will write the whole buffer, including the characters past the end of the string, again use strlen().

      Performing a strcat() on buffer without testing for buffer overflow is dangerous, especially in an iterative loop. Do you know buffer will always be large enough?

      3)
      That may be the case, syntactically correct code does not imply semantic correctness. However, it is best to get the compiler to work as hard as possible to ensure code quality: Set at least the following command line options:

      -Wall -Werror -Wformat

      This makes the compiler generate more warnings, and then treat them as errors. Also the last option allows checking of format specifier consistency in printf/sprintf etc (this my not apply to your code, but can be left in in any case).

      Clifford.

       

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.