Code terminates trying to open file

[Lucas Tiridath]

Hi. First post here so if I'm posting in the wrong place or something, please do say.

I am trying to open a text file in C++ using the following code:

// Open file
ifstream file;
cout << "About to Open\n";
file.open(sFileAddress, ios::in);
cout << "Open\n";

As you can see, I have added a couple of test couts to the code. The complete code compiles file. I run the executable in from the terminal with a batch file. The "About to Open" appears in the terminal. However there is then nothing before the next command in the batch file (pause). I get no error message. I can only conclude that the code after the file.open is not being executed. I have tried other ways of getting a message out from the code following the file.open such as writing a file but I have got nothing. I have also tried replacing the cout with cerr in case the cout was being diverted somewhere else but I still get nothing.

I'm using the MinGW compiler and I'm developing in a WinXP 32 bit.

I wondered if anyone had any idea why it might be silently terminating the program or if it's not, then why I'm getting nothing from my code after this point. If not, then is there anything I can try to get an error message that might help me to fix the problem?

Thanks in advance for your help.

[helios]

The streams code in some versions of MinGW is hopelessly broken, so the fact that nothing is being printed doesn't necessarily mean that the control flow didn't reach that part of the code.
What version are you using (g++ --version)? Does the error persist if you try a different compiler?

[Lucas Tiridath]

Hi. Thanks for the response. I've done some tests on your advice in MSVC++ and MinGW with simplifying the full source. By commenting out large chunks, I've got it to work. That leads me to believe that the error lies in a bit of code that I didn't post so I apologise. It was just that as I say, I put two cout lines and one displayed and the other didn't so I thought that that must mean that the error was between them.

The streams code in some versions of MinGW is hopelessly broken, so the fact that nothing is being printed doesn't necessarily mean that the control flow didn't reach that part of the code.

What exactly do you mean here? Is MinGW a bad choice as a compiler? In what sense broken? Also if the code were broken, then surely I would get an error? If the control flow did reach that bit of the code, then why wouldn't I be able to see the output in the terminal? Thanks for your help in this. I'm still trying to learn :).

What version are you using (g++ --version)?

I'm using version 4.5.2.

Thanks again.

EDIT: OK I've tracked it down and it turns out that the error was the result of a string overflow. I was using the code:

char *temp = new char[strlen(argv[1])];
strcpy(temp, argv[1]);
strcat(temp, "*.*");
hFind = FindFirstFile(temp, &data);

when it should have been:

char *temp = new char[strlen(argv[1]) + 1];
strcpy(temp, argv[1]);
strcat(temp, "*.*");
hFind = FindFirstFile(temp, &data);

Again just to help me learn, why would this have caused the error I experienced? I'm guessing it was overwriting something important by a byte but is there anything that should have indicated to me that this was the kind of error I was experiencing so that I can better track them down in future? Thanks!

[helios]

What exactly do you mean here? Is MinGW a bad choice as a compiler? In what sense broken? Also if the code were broken, then surely I would get an error? If the control flow did reach that bit of the code, then why wouldn't I be able to see the output in the terminal? Thanks for your help in this. I'm still trying to learn :).
[...]
I'm using version 4.5.2.

Never mind, then.
MinGW 3.x, which is the version that comes with the last version of Dev-C++ (which is why I asked), has numerous bugs ranging from compiler crashes to incorrect code generation and bugs in the standard library. 4.x is alright, as far as I can tell.

char *temp = new char[strlen(argv[1]) + 1];
strcpy(temp, argv[1]);
strcat(temp, "*.*");

This is still incorrect. It should be (strlen(argv[1]) + 4) (3 to hold "*.*" and 1 for the terminating character).

Again just to help me learn, why would this have caused the error I experienced? I'm guessing it was overwriting something important by a byte but is there anything that should have indicated to me that this was the kind of error I was experiencing so that I can better track them down in future? Thanks!

The fun thing about C/++ development is that these kinds of mistakes produce bizarre bugs that are completely unpredictable and have (as far as the programmer can tell) little to do with the actual problem. You can overflow a buffer in the part of the program that plots a graph and nothing may go wrong until the program's been running for five days straight and it crashes when it tries to ask the system for the time of day.
There's no real solution other than "be careful" and "don't put yourself in situations when you have to do things that cause these bugs if your screw up".
There's a tool for Linux called Valgrind that helps detecting and identifying these bugs. There's similar tools for Windows, too, but I don't know of any that is both as good and free.

[Lucas Tiridath]

This is still incorrect. It should be (strlen(argv[1]) + 4) (3 to hold "*.*" and 1 for the terminating character).

Thanks again! Made that mistake in a couple of places. I'm leaning ;)

MinGW 3.x, which is the version that comes with the last version of Dev-C++ (which is why I asked), has numerous bugs ranging from compiler crashes to incorrect code generation and bugs in the standard library. 4.x is alright, as far as I can tell.

Oh good. I'm working in NetBeans so I just downloaded the latest version I could find from the MinGW website.

The fun thing about C/++ development is that these kinds of mistakes produce bizarre bugs that are completely unpredictable and have (as far as the programmer can tell) little to do with the actual problem.

Fair enough. So long as there isn't anything I'm missing then! At least now I'll know why my cout << "test" technique might be totally inaccurate for bug hunting :).

Thanks again for the advice. I'm sure I'll be back next time I manage to tie myself up in virtual knots.