Sunday, March 29, 201512:03:56 PM
 Users online: 0 You are here >> Home > Programming
 Forums | Programming Forums searchForum FAQ
 1 inexplicable c read error, help plz!
 dr_w00t  12/4/04 7:27:14 PM Overlord Hi, I am writing a large program, and upron attempting to read and write some files, errors were occurring. I wrote this quick little tester to see what was going on:  ------------------ #include int main() { FILE *inFile, *outFile; char inChar ; inFile = fopen("in.txt", "r"); printf("input file is open") ; outFile = fopen("out.txt", "w"); printf("output file is open") ; while(!feof(inFile)) { inChar = fgetc(inFile); printf("char read") ; fputc(inChar, outFile); printf("char writen") ; } } ------------  Compiles fine, but on rinning, it doesn't even get as far as the first print statement, leading me to beleive the problem is with my fopen. (I realise print statements aren't the best way to debug, but !) The file in.txt exists in the same correct directory, and is not protected. I am running cywin on windows XP pro. jGrasp gives me the ever heaplful message :"jGRASP cygwin wedge2: process died on signal 11" Edited by dr_w00t: 12/4/2004 7:28:33 PM ----- Antec Super LANboy, 2x120mm Fans + speed control, XP2500+ @ 2.27 (11.5x197) 1.775Vc, Bitspower all copper HSF, 512MB Hynix DDR333 @ DDR396 1.6Vm, Epox 8K9A1 KT400 MoBo, 9800PRO @ 459core/365mem, WD 120GB HDD 8MB Cache, FSP 400W PSU w/ 120mm Fan w00t. Blitz[VFF]  12/4/04 7:37:13 PM Guru If it isn't getting as far as the first printf then it looks as though fopen is encountering a problem ... if fopen fails it returns a null pointer, so nothing should be crashing unless you try to use that null ptr (which you're not doing) so that leads me to believe that the problem lies in something other than your code ie. read/write permissions in your folder or files. ----- "... Compadres, it is imperative that we crush the freedom fighters before the start of the rainy season. And remember, a shiny new donkey for whoever brings me the head of Colonel Montoya... " stadl  12/4/04 7:38:26 PM HeroGuru first tip: add \n to the end of the printf debug statements. Buffering of the stdin/stdout file streams can mean that your text won't output at the exact time the printf statement is executed. A newline character typically causes it to flush, or you can explicitly fflush(stdout) if your paranoid, but it shouldn't need it. Second tip: Check that the returned pointers from fopen() are not null. Signal 11 is typically segmentation violation. This means that your process accessed memory it didn't own, and a common source of this is deferenencing null/dead pointers, or array out of bounds. Most likely you have a null return from fopen, which is then SEGV inside feof or fgetc. The process is then killed before your debug output gets displayed. ----- ...so brilliant in fact, that by simply harnessing the power of one live frog, it.. it.. uhh. World domination has encountered a momentary setback. Talk amongst yourselves. Waffles, Lots of Waffles... And Chips... dr_w00t  12/4/04 7:53:12 PM Overlord stadl you were absolutely correct, code updated to this:  --------------- #include int main() { FILE *inFile, *outFile; char inChar ; printf("starting\n") ; if ((inFile = fopen("in.txt", "r")) == NULL) { printf("yup it is null\n") ; } printf("input file is open\n") ; outFile = fopen("out.txt", "w"); printf("output file is open\n") ; while(!feof(inFile)) { inChar = fgetc(inFile); printf("char read\n") ; fputc(inChar, outFile); printf("char writen\n") ; } } --------------  prints the following:  starting yup it is null input file is open output file is open  The question is, why is my file NULL, as it certainly exists in the correct directory, and as far as I can see, there are no access privelages associated with it... ----- Antec Super LANboy, 2x120mm Fans + speed control, XP2500+ @ 2.27 (11.5x197) 1.775Vc, Bitspower all copper HSF, 512MB Hynix DDR333 @ DDR396 1.6Vm, Epox 8K9A1 KT400 MoBo, 9800PRO @ 459core/365mem, WD 120GB HDD 8MB Cache, FSP 400W PSU w/ 120mm Fan w00t. dr_w00t  12/4/04 8:19:45 PM Overlord OK I have done some sluething and the following code:  ---------------- #include #include #include int main() { FILE *inFile, *outFile; char inChar ; printf("starting\n") ; if ((inFile = fopen("in.txt", "r")) == NULL) { printf("yup it is null\n") ; } printf("input file is open\n") ; outFile = fopen("out.txt", "w"); printf("output file is open\n") ; if (!inFile) { printf ("Error is: %s\n", strerror (errno)); exit (EXIT_FAILURE); } else { printf("File OK\n"); } while(!feof(inFile)) { inChar = fgetc(inFile); printf("char read\n") ; fputc(inChar, outFile); printf("char writen\n") ; } } ---------------  produces the following output:  starting yup it is null input file is open output file is open Error is: No such file or directory  So there is no such file or directory eh??? I am positive the file in.txt exists in the same directory as both the source and the executable of the file I am running. Anyone suggest an sloutions? ----- Antec Super LANboy, 2x120mm Fans + speed control, XP2500+ @ 2.27 (11.5x197) 1.775Vc, Bitspower all copper HSF, 512MB Hynix DDR333 @ DDR396 1.6Vm, Epox 8K9A1 KT400 MoBo, 9800PRO @ 459core/365mem, WD 120GB HDD 8MB Cache, FSP 400W PSU w/ 120mm Fan w00t. hetman  12/4/04 8:20:47 PM Guru Ah, the perils of trying to run linux on windows... why not forgo the middle man ;) Edited by hetman: 12/4/2004 8:21:04 PM ----- Spadaj na drzewo! ... Tu es stultior quam asinus. dr_w00t  12/4/04 8:28:36 PM Overlord Quote by hetman Ah, the perils of trying to run linux on windows... why not forgo the middle man ;) I would like to run over the middle man very slowly with a steam roller, but the assignment is to run on a win32 environment. I used to do all my programming on Solaris @ Flinders Uni, but UQ uses Windows XP for most topics... 0_o Plus I am a Java programmer, and my enourmous mental faculty is grappling with the simple concept of pointers and the apparent rickitiness of weakly typed cryptic man paged C vs Java and it's standard API. Going from an obviously documented well structured to a seemingly poorly documented apparently 2 dollar laguage like C is wiggin me out. I relaise that C is none of the above, though it seems that way coming back from Java. ----- Antec Super LANboy, 2x120mm Fans + speed control, XP2500+ @ 2.27 (11.5x197) 1.775Vc, Bitspower all copper HSF, 512MB Hynix DDR333 @ DDR396 1.6Vm, Epox 8K9A1 KT400 MoBo, 9800PRO @ 459core/365mem, WD 120GB HDD 8MB Cache, FSP 400W PSU w/ 120mm Fan w00t. freespace  12/4/04 10:37:01 PM Champion Quote by dr_w00t Plus I am a Java programmer, and my enourmous mental faculty is grappling with the simple concept of pointers and the apparent rickitiness of weakly typed cryptic man paged C vs Java and it's standard API. Going from an obviously documented well structured to a seemingly poorly documented apparently 2 dollar laguage like C is wiggin me out. I relaise that C is none of the above, though it seems that way coming back from Java. Makes my blood boil reading that ;) As for your problem, how are you running the program? from cmd.exe ? If not, your IDE may cause some problems. Secondly, case just might matter, to ensure they are correct. ----- By perseverance the snail reached the ark. http://freespace.ausgamers.com http://glutbase.ocmelbourne.com/ dr_w00t  12/4/04 11:19:04 PM Overlord Quote by freespace Makes my blood boil reading that ;) Yeah I realise the versatility and power of C blah blah blah, but I'm a n00b @ C so I gotta whinge ;) With familiarity to C, no doubt I will come to appreciate it. As for your problem, how are you running the program? from cmd.exe ? If not, your IDE may cause some problems. Secondly, case just might matter, to ensure they are correct. The program is writen using jGrasp as an editor, it integrates a run command, as well as a debug command. I compile with cygwin to a win32 binary and run it on Windows XP with admin privilages. I have all the relevant (windows) libraries from cygwin. Cases are matched i.e. all lowercase. To KISS filenames are simple xxx.xxx and the directory is c:\uni. I'm bewildered. There is obviously either something boneheaded I am doing, or some property or attribute of c/windows file acces I am unaware of. I am failry certain my usage of C in this case is correct, so I am jiggered. ----- Antec Super LANboy, 2x120mm Fans + speed control, XP2500+ @ 2.27 (11.5x197) 1.775Vc, Bitspower all copper HSF, 512MB Hynix DDR333 @ DDR396 1.6Vm, Epox 8K9A1 KT400 MoBo, 9800PRO @ 459core/365mem, WD 120GB HDD 8MB Cache, FSP 400W PSU w/ 120mm Fan w00t. freespace  13/4/04 11:07:41 AM Champion run it from cmd.exe. cd into uni, and run it from there, see if that helps. And as far as I can see, what you are doing is correct. Try also using "C:\uni\in.txt" as the path. ----- By perseverance the snail reached the ark. http://freespace.ausgamers.com http://glutbase.ocmelbourne.com/ pbkg  13/4/04 11:36:48 AM HeroChampion The program is writen using jGrasp as an editor, it integrates a run command, as well as a debug command. I compile with cygwin to a win32 binary and run it on Windows XP with admin privilages. I have all the relevant (windows) libraries from cygwin. I would be fairly certain that your problems lies in that fact that you are running via the editor, which will have set the current working directory to it's own directory, rather than c:\uni (for example), so that is where it will be looking for the file. You can either hard code the path as freespace said. Otherwise, to check if this is the case, have a look at getcwd() which will get you the current working directory, or else something like getenv("CWD") which if memory serves me correctly will give you the current working directory undex *nix, but I can remember testing it on Windows (and can't check it at the moment either...). If you are in the editor's directory, and don't want to hard code path's, then you can use chdir("c:\my path") edit: forget the closing bracket just above, and noticed just after hitting post message.... Edited by pbkg: 13/4/2004 11:38:28 AM ----- "To me, reading Perl is a little like trying to understand Norwegian. A minority of things - essentials like "Help!" or "Hello" - I can probably understand. The rest is just gobbledygook." Daniel Bowen.
 1
Forums | Programming