PRINT to * or 6

[Espen_M_]

If I compile with the F2003 standard-semantics option set I discovered that printing to the * UNIT is the same as printing to UNIT 6 if a file with that unit has been OPENed. After searching around a bit I found out that it might have something to do with the constant OUTPUT_UNIT in the standard intrinsic module ISO_FORTRAN_ENV. Why should this module influence my program if I'm not USEing it? I find this especially strange in light of that I cannot use OUTPUT_UNIT unless I USE the module.

I don't know the history of this module, but I guess it has something to do with code portability..? If so, I find it strange to sacrifice code predictability for portability...

Would it be possible to have a value for OUTPUT_UNIT that does not take away a valid UNIT number? For instance by using some IEEE 'special numbers'?
As I generally use enumerators for UNIT numbers (to get a kind of automatic numbering) it is awkward having to skip particular, and possibly processor dependent, values.

[IanH]

If your coding standard allows then bump up to F2008 and use NEWUNIT. This gives you automatic numbering without having worry about colliding with unit numbers preconnected by the compiler or by other code in your program (perhaps not written by you, or perhaps written by you long enough ago (yesterday in my case) that you can't remember what units it uses). Fixed unit numbers are an anachronism. Despise them. (Unit numbers are integers so there are no special IEEE things in their range. Number 6 being the equivalent of standard output is a somewhat common convention (also 5 for standard input) - hence you will see advice to only use unit numbers > 10. (Why 5 and 6? Discussions in the past on c.l.f have had some of the old timers reminisce about how the first few unit numbers were commonly pre-connected to a stone tablet reader and some guy with a chisel, etc - neither of those peripherals remain in common use with today's hardware.) Now guessing - Intel perhaps could have used -2 or similar (but not -1!) for OUTPUT_UNIT, but that would have borked existing code that used the previously documented value of 6 as the output. The way that the description of * as the unit specifier in a write statement (* in a print statement is a format, not a unit) is written in the standard means that WRITE (*, ...) and WRITE (OUTPUT_UNIT, ...) are equivalent, and the behaviour of WRITE (OUTPUT_UNIT, ...) in the face of you "re-opening" OUTPUT_UNIT is also well defined. See also /assume:old_unit_star, which is included in the bag of options turned on by /standard-semantics)

[Steven_L_Intel1]

The reason this is done is that the current standard allows you to OPEN the "standard output" unit. It doesn't matter whether you use the ISO_FORTRAN_ENV module or not - that's there so you can see what unit number does correspond to unit *. If we didn't make unit * a regular numbered unit, you could not OPEN it (it's otherwise a negative unit number) and that would not meet the standard. Assuming that unit * and unit 6 are distinct is not something supported by the standard and different compilers make different choices here. If you use /standard-semantics, you're telling us you want the compiler to choose the standard's rules rather than what we did in the past (where they are different.)

[IanH]

Steve Lionel (Intel) wrote:
...If we didn't make unit * a regular numbered unit, you could not OPEN it (it's otherwise a negative unit number) and that would not meet the standard...

Why couldn't you make OUTPUT_UNIT a negative number?

[Steven_L_Intel1]

The standard says that external unit numbers are non-negative, unless they are from use of NEWUNIT=.

[IanH]

Ok. In the text following the description of a file-unit-number in F200[3|8] there's an "or" separating the various requirements on its value that appears to give vendors a bit more latitude than that, similarly the wording of the description of OUTPUT_UNIT implies otherwise. That's why I figured backwards-compatibility was the reason for sticking with 6.

[Steven_L_Intel1]

Now that I read it again, I think you're right. We've changed our default on this over the years. An interesting topic. I don't think we'll change again, though. As I said, some other compilers use 5 and 6 (and 0!) by default for these units.