Are Fortran control characters (carriage control) still implemented in compilers?

In the book Fortran 95/2003 for Scientists and Engineers, there is much talk given to the importance of recognizing that the first column in a format statement is reserved for control characters. I've also seen control characters referred to as carriage control on the internet.

To avoid confusion, by control characters, I refer to the characters "1, a blank (i.e. \s), 0, and +" as having an effect on the vertical spacing of output when placed in the first column (character) of a FORMAT开发者_StackOverflow statement.

Also, see this text-only web page written entirely in fixed-width typeface : Fortran carriage-control (because nothing screams accuracy and antiquity better than prose in monospaced font). I found this page and others like it to be not quite clear.

According to Fortran 95/2003 for Scientists and Engineers, failure to recall that the first column is reserved for carriage control can lead to horrible unintended output. Paraphrasing Dave Barry, type the wrong character, and nuclear missiles get fired at Norway.

However, when I attempt to adhere to this stern warning, I find that gfortran has no idea what I'm talking about.

Allow me to illustrate my point with some example code. I am trying to print out the number Pi:

PROGRAM test_format
IMPLICIT NONE

REAL :: PI = 2 * ACOS(0.0)

WRITE (*, 100) PI
WRITE (*, 200) PI
WRITE (*, 300) PI
100 FORMAT ('1', "New page: ", F11.9)
200 FORMAT (' ', "Single Space: ", F11.9)
300 FORMAT ('0', "Double Space: ", F11.9)
END PROGRAM test_format

This is the output:

1New page: 3.141592741
Single Space: 3.141592741
0Double Space: 3.141592741

The "1" and "0" are not typos. It appears that gfortran is completely ignoring the control character column.

My question, then, is this:

Are control characters still implemented in standards compliant compilers or is gfortran simply not standards compliant?

For clarity, here is the output of my gfortran -v

Using built-in specs. Target: powerpc-apple-darwin9 Configured with: ../gcc-4.4.0/configure --prefix=/sw --prefix=/sw/lib/gcc4.4 --mandir=/sw/share/man --infodir=/sw/share/info --enable-languages=c,c++,fortran,objc,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --disable-libjava-multilib --build=powerpc-apple-darwin9 --host=powerpc-apple-darwin9 --target=powerpc-apple-darwin9 Thread model: posix gcc version 4.4.0 (GCC)

In years past, ignoring this use of the first column could cause bad things on a line printer, like page ejects -- but when was the last time that you saw a line printer? Otherwise it was output device, compiler and OS dependent. The advice of "Fortran 95/2003 for Scientists and Engineers" was excellent for about 15 or 20 years ago. With terminals, postscript and other modern printers, column one isn't special any more. I don't pay special attention to column one anymore and I haven't gotten into trouble.

The Fortran 2003 standard lists carriage control as deleted, which is something that the Fortran language standards rarely do. See page 359 of "Fortran 95/2003 explained" or page 326 of "The Fortran 2003 Handbook". Perhaps selecting -std=f2003 or -std=f2008 with gfortran will guarantee that column 1 won't be used a carriage control so that "bad things" are completely impossible.

Common printer hardware would do special things based upon the content of column 1. Note that line printers didn't have a print head that moved back and forth--they had a chain or drum and 132 hammers, each associated with a byte in a buffer. When the character in front of the hammer matched the one in the buffer, the hammer would be energized and that byte of the buffer would be blanked. When the entire buffer was blank, the printer would load the next line.

Printers had no concept of carriage-return, line-feed, or form-feed control characters. Instead, they used the first character of the buffer to indicate what if anything the paper should do before printing each line. Certain codes would advance the paper by fixed amounts; other codes would select one of (IIRC) eight columns on a paper tape reader, and advance the printing paper and paper tape together until a hole was spotted on the appropriate column. Traditionally, the paper tape would be a loop the same length as a printed page, and column 1 would have a single hole; the paper would be lined up so the column-1 hold would occur where printing was supposed to start on each page. I've read of one shop which used a double-length type, and had columns 7 and 8 line up with inward- and outward-facing perforations of the fanfold paper. Nice trick--I wonder how common it was.

In any case, carriage-control characters may be a convention strongly associated with the language, but they're a hardware feature rather than a language one. Indeed, there's no particular guarantee a "1" will go to top of page, beyond the fact that most if not all shops happened to set up their carriage-control tape that way.

I believe Fortran 95 was the last version to specify the special meanings for characters in column 1 of printed output.

Carriage control characters were defined for output to printers. Output to other kinds of devices (for example punched cards, paper tape, or those newfangled magnetic rotating roundy things) didn't have them. If your output goes to a disk file then gfortran is doing the right thing.

Edit: gfortran is really doing the right thing. If you want to command a printer driver to interpret Fortran carriage control characters instead of printing them literally, say so in the lpr command by using the f filter option. See for example http://www.computerhope.com/unix/ulpr.htm

Yes, Fortran compilers still support Fortran carriage control, though often it is disabled by default. In Intel Fortran, for example, one needs to open the file with the non-standard (but widely implemented) CARRIAGECONTROL='FORTRAN' option. Look to see if gfortran has something similar.

That said, I would not recommend coding new applications using this convention, as it may not work the way you want on all output devices.