Possible fopen() bug?
Rick Murray (539) 13870 posts |
I have a bit of code that responds to a menu selection by opening a file, reading script commands, and then executing them one by one. Something like:
One of the commands is a command to invoke a new menu. In the process of doing so, it uses fopen() and then fclose() on the same handle (it is module-specific). When DoExec returns to the above bit of code, this time with fp having been messed up, the machine hangs. Now, I am well aware that this is a bug in my program, and as such I have worked around it by detecting the new menu command and if found, closing the file before calling DoExec and dropping out of the procedure immediately afterwards. [makes debugging something of a PITA as well; I finally sussed this by using a modified DADebug (to serial port on a ticker), crashing the machine, and then waiting to see what turned up in HyperTerm] |
Jeff Doggett (257) 234 posts |
fp is NOT a file handle. It is a pointer to a structure that the clib uses to contain the file status. |
Rick Murray (539) 13870 posts |
Then please allow me to correct myself: However, to freeze the machine because of an attempt to read using a stale file structure pointer, that’s not so good… |
Jeff Doggett (257) 234 posts |
You’re right, it’s not so good. An invalid pointer should never stiff the whole machine, but RiscOS does lack the memory protection of other systems so it doesn’t really surprise me. |
Dave Higton (1515) 3555 posts |
"Jump into my arms. Of course I’ll catch you." <thudsplat> "Why on earth did you do that? You should have known that my arms weren’t real. Look what a mess you’ve made. Blood everywhere." |
Dave Higton (1515) 3555 posts |
The main reason that C programmes execute so fast is that there is little error checking at run time. |