Possible fopen() bug?

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:

fp = fopen(....);
while (!feof(fp))
   ...read a line
   ...tidy it
   DoExec(line);

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.
However, to freeze the machine because of an attempt to read from a stale file handle, that’s not so good…

[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]

fp is NOT a file handle. It is a pointer to a structure that the clib uses to contain the file status.
If you have closed the file then the structure will have been released. You are now using a stale pointer.

If you have closed the file then the structure will have been released. You are now using a stale pointer.

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…

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.
Very few C library calls validate their pointers, they just take it for granted that the programmer hasn’t screwed up!

"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."

Very few C library calls validate their pointers, they just take it for granted that the programmer hasn’t screwed up!

The main reason that C programmes execute so fast is that there is little error checking at run time.