Windows errors for valid Fortan io

[andrew_4619]

I have converted an application with an awful lot of  user interface from  QuickWin to Windows and am currently at the testing/fixing phase. As such I have a custom error trapping routine inserted all over the place looking at the windows error status from the sdk getlasterror() and logging such events along with a stack trace, error code etc.

I seem to get an irritating number of 'false errors' from valid Fortran i/o, for example a Fortran INQUIRE statement on a file  with EXIST or IOSTAT generates a windows error code if the file does not exist. I expect the Fortran runtime provokes windows by trying to open the file and then returns the Fortran status based on that status. It would seem to be a bit more friendly if the Fortran runtime reset and spurious errors that it generated.

Are there any options that would work around this? I suppose I could start replacing Fortran with Sdk file utilities.but that seems like wasted effort.

[IanH]

Why are you calling GetLastError after INQUIRE?

Could you strategically use SetLastError prior to the operation that your error trapping really covers?

My recollection is that some windows API's will set the last error code to a non-zero value even if the API notionally succeeds (as determined by the API function result), so using GetLastError alone for error detection is going to give you false positives.

[Paul_Curtis]

I agree with Ian -- GetLastError() is only for use immediately following a WinAPI call. IVF provides no information on how various Fortran statements are realized as API calls, so the results from calling GLE in an indirect context will be neither meaningful nor correct.

Suggestion: if you're really trying to implement Windows code using Fortran, why not ditch the antiquated Fortran file i/o altogether and use the direct WinAPI handle-based file routines instead?  In my experience, they provide much better performance, are easier to use, and also allow vastly improved granular control over i/o.  I have posted code samples several times to this forum.

[Steven_L_Intel1]

Yes, INQUIRE tries to open the file to see if it exists and is openable by Fortran. As others have said, don't look at GetLastError after a Fortran I/O operation - especially an INQUIRE.
 

[andrew_4619]

In general with many sdk routines the functions return a NOK status and then you must call gestlasterr() to find out why. I am not specifically calling getlasterror() after INQUIRE that in itself would be pointless.  This was just an example of the Fortan runtime leaving and error state handing that can be detected  at a later point.

The specific diagnostic routine is some additional problem finding/validation and is not part of the normal error trapping and normal function of the program and indeed will not be present in the final version. For example in some routines (mostly new ones) there are some diagnostic trace on entry and exit.

 IanH's comment "My recollection is that some windows API's will set the last error code to a non-zero value even if the API notionally succeeds (as determined by the API function result), " is indeed what the sdk documentation says but is not what  I have found to happen in practice in 99% of cases.

@Paul, "not ditch the antiquated Fortran file i/o" that is a possibility I was considering but I am reticent to go changing a whole ruck of code that isn't broken at this point in time. It isn't a performance issue as the application is not limited  by file i/o in ant way.

@steve. Thanks for the info. I understand your point. I think it is rather mean the the runtime leaves the system with an error state that the coders knew they had created.It would have been more friendly to reset that..