topic In general with many sdk in Intel® Fortran Compiler

Windows errors for valid Fortan io

andrew_4619 — Tue, 11 Feb 2014 01:23:41 GMT

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.

Why are you calling

IanH — Tue, 11 Feb 2014 01:40:36 GMT

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.

I agree with Ian --

Paul_Curtis — Tue, 11 Feb 2014 01:56:45 GMT

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.

Yes, INQUIRE tries to open

Steven_L_Intel1 — Tue, 11 Feb 2014 03:59:14 GMT

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.

In general with many sdk

andrew_4619 — Tue, 11 Feb 2014 07:52:32 GMT

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