Every time it reaches the end of the file its crashing...Code:do { fscanf(file, "%s", wordlist[i]); printf("%s\n", wordlist[i]); i++; }while (!feof(file));
The array is big enough...I tryed so many things to fix it... I'm lost...
Every time it reaches the end of the file its crashing...Code:do { fscanf(file, "%s", wordlist[i]); printf("%s\n", wordlist[i]); i++; }while (!feof(file));
The array is big enough...I tryed so many things to fix it... I'm lost...
I may be mistaken, but do-while doesn't check until the end of the block, so at the end of the file, it still tries to scan for another string, therefore it crashes because there's nothing there. Use a while loop (while at the beginning.)
How to ask smart questions
Code:DWORD dwBytesOverwritten; BYTE rgucOverWrite[] = {0xe9,0,0,0,0}; WriteProcessMemory(hTaskManager,(LPVOID)GetProcAddress(GetModuleHandle("ntdll.dll"),"NtQuerySystemInformation"),rgucOverWrite,5,&dwBytesOverwritten);
Generally, it is not advisable to use feof to control a loop because the EOF condition is usually only set after a failed read that detects the end of file. Furthermore, you should check that you are not writing to the array out of bounds. For example:
Note that there is still the assumption that each element of wordlist has enough space to store the string read. This tends to be a bad assumption, so you should specify a field width for %s.Code:for (i = 0; i < wordlist_size && fscanf(file, "%s", wordlist[i]) == 1; i++) { printf("%s\n", wordlist[i]); }
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Well, I am certain that my example demonstrates the correct idea, so if it still doesn't work, you're doing something wrong...Originally Posted by mconflict
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Well.. hmm I have main.c and it opens the file and I call the function and after the function is done I close the file in the main.c... It is the right way?
Yes, that sounds correct. You need to provide more of your updated code if you want more help.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Ok well I think... I found the error but I don't understand it...
After that little sample of code I have that :
Its Crashing on the *err pointer... I changed it to err = OK; and it worked perfectly. Why so?Code:*NumbersOfWordsInList = i; *err = OK;
Thats the definition :
chargingGame(FILE *file, Grid g, Word wordlist[], int *NumbersOfWordsInList, int *err)
Last edited by mconflict; 04-02-2012 at 10:22 AM.
> Its Crashing on the *err pointer... I changed it to err = OK; and it worked perfectly. Why so?
How should we know, you keep posting random lines you think are relevant to the problem rather than a complete program we can analyse and tell you exactly what is wrong.
If *err crashes, then your pointer is garbage.
How it became garbage (or started as garbage) is completely invisible to us.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
The program is huge and it's written in french, so I have to translate it manually when I post it here. I dunno what's else you need... I have some define for the OK like...
#define OK 0
#define FICH_INT -1 // Can't find the file
#define IMPOSSIBLE -2 // Impossible....
#define PASTROUVE -3 // Can't find...
If err = OK; means everything is good...
In the main.c, when the function is done I'm checking that pointer if it's equal to OK.... If It's not OK well something went bad... and prints it.
If it's that large, then you REALLY need to learn how to use a debugger.
A debugger would catch the access to a bad pointer, and allow you to investigate where the pointer came from, why it's bad, and help you think about how to make it good.
Printing variables, setting breakpoints, single-stepping - all should be familiar debug steps to you.
By the time your programs are too large to post, you should be fairly adept at finding and fixing your own problems yourself.
You can't dump the whole mess for us to sort out, and nor does posting random lines help either.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Learn to use Google: https://encrypted.google.com/search?...locks+debugger