stderr output?

[Dave Offiler]

Helpdesk enquiry ID=177 (from Axel) raised the issue of extraneous output to stderr (this specific issue is fixed for v7.1). However, this raises a policy issue of whether ROPP (F90 code) should write to stderr at all.

A quick Google and Wikipedia shows that it is common for compilers to map unit number 0 to stderr. But unlike unit 5 (stdin) and 6 (stdout) which are reserved, this 0=stderr is not ISO-standard, merely convention, and therefore not guaranteed to work universally. Wikipedia (​http://en.wikipedia.org/wiki/Standard_streams#1950s:_Fortran) flags this practice as 'dubious'. The ISO-standard allows any non-negative number (but usually the range is 1-99), but does not assign any specific meaning to 0 (only 5 and 6).

The early ROPP releases used Christian's message library which called a C-routine to do the output (including stderr, which _is_ a standard stream in C), but we took the decision long ago to remove all C code, and output all messages to stdout. At some point later (Huw?), it seems message.f90 writes to stderr via unit 0 for certain message types (e.g. FATAL_ERROR). Was this by user request?

This pros and cons of using this non-standard (but common) unit number ought to be reviewed and a recorded decision made whether to accept the principle and practice of using Fortran unit 0 for stderr messages, or whether to direct all messages to stdout only.

Apart from the specific Helpdesk problem, the current practice has not knowingly caused any problems - though testing of conditions which would result in a run-time output to stderr is hardly thorough. A small test program should first be setup and run with at least all the compilers available to us (MetO) on Linux, AIX and Cygwin and others if possible to see if any do not map unit 0 to stderr (where such a concept exists).

[Dave Offiler]

F90 test program

[Dave Offiler]

Driver script

[Dave Offiler]

Tested a trivial F90 program with a driver script (attached). Basically the program just writes some text to stream 5 (stdout) and stream 0 (stderr) while the driver compiles it then runs it twice - the first should write the text to the screen for both streams, the seconds redirects stderr to a file which is then checked for the expected output. This is repeated for all the usual supported/available F90 compilers on the local system.

Have run this on Linux (RHEL6, all compilers used for ROPP testing), AIX (xlf95) and Cygwin (gfortran, g95); in all cases, output to stderr (stream 0) ended up as as expected.

This confirms that F90 stream zero is in practice consistently equivalent to stderr on POSIX-type systems (at least those tested), but as noted this mapping is not ISO-standard and so not guaranteed to work everywhere or in the future. At worst, a program may fail to compile if UNIT=0 is flagged as illegal (the ISO standard requires the UNIT value to be 1 or greater) or it might fail at run-time if this condition occurs; the output may disappear entirely (effectively > /dev/null) or it might always go to the screen (or mapped to stdout, wherever that is directed). But at least for all the current compiler/OS combos used for ROPP testing, stream 0 does go to stderr, either to the same place as stdout or re-directed elsewhere.

While the intent is for ROPP to employ ISO-standard code, by necessity, we already use some non-ISO (but industry-standard) features such as CALL EXIT() and stream 0 mapped to stderr might be considered to be in the same boat.

It should still be raised with ROPP-GG whether stderr is acceptable in principle. If the concept of stderr in Fortran is rejected as bad practice, it would be trivial to change the output stream number back to 5 (stdout), since the only occurance (that I'm aware of) is in ropp_messages().

[Dave Offiler]

Raised as an agenda item and discussed at ROPP GG of 29/7/2014. DMI confirm they have no requirement to separate stderr from stdout in their processing chains, and no-one else present felt the need to retain stderr The GG agreed to my recommendation to remove the Unit 0 (> stderr) from the messaging sub-system in ROPP_UTILS (the only place this occurs) with the standard Unit 6 (> stdout).

Changes applied to branch do_exitcodes, checked by compilation make at module level (default ifort) and running make test in tests/

Checked in as [4286].

[Ian Culverwell]

I'm not including this in ROPP8.0. We don't know how many users direct output to stderr. If stderr=0 causes problems later on, the solution is recorded here.