RFortran hard-crashes when an invalid filename is provided (eg, for the log file)

[GoogleCodeExporter]

*** What steps will reproduce the problem?

Attempt to run RFortran with a log file name that contains special characters 
such as &, *, etc

*** What is the expected output?

As this usage is not allowed, an error message from RFortran is expected.

*** What do you see instead?

Hard crash somewhere in the log utilities procedures (on the OPEN statement).

*** What version of RFortran are you using?

revision 628

*** If you have a coding solution to this defect please include the file
(or preferably a svn patch) as an attachment

Proposed solution: The OPEN statements in RFortran need to be supplemented with 
IOSTAT checking, and appropriate error handling. Otherwise RFortran crashes, 
which can be difficult to debug especially to a general user.

This needs to be done throughout, reporting any errors in a consistent way.

cheers,
d

Original issue reported on code.google.com by dmitri.k...@gmail.com on 1 Jun 2011 at 5:27

[GoogleCodeExporter]

Michael,

Any chance you could take a look at what's causing this? It may be in Mutilslibs

I'm a bit swamped this week.

Mark

Original comment by mark.th...@gmail.com on 5 Jun 2011 at 11:48

[GoogleCodeExporter]

Hi Mark,

See attached a patch to MUTILSLIB that fixes this problem, d-style.

The problem is that an error in opening a log file, well, cannot really be 
written to a log file ..

Hence my solution is to return 'err' and 'message', like in all DMSL prox. The 
calling proc should then check if err==EXIT_SUCCESS, and take action 
accordingly.

I made them optional, which means that your existing code will still compile 
(but will not have access to the improved functionality).

NB: This patch is needed for BATEA / DMSL r419+.

cheers,
d

Original comment by dmitri.k...@gmail.com on 23 Jun 2011 at 2:39

• Added labels: Priority-critical
• Removed labels: Priority-major

Attachments:

• init_log_DKpatchErrorHandling23June2011.patch

[GoogleCodeExporter]

Implemented in r101 of MUtilslib. The branch\ver-3.0.x now links to this 
revision of MUtilslib and hence this issue is resolved.  

Original comment by mark.th...@gmail.com on 2 Jul 2011 at 5:44

• Changed state: Fixed