Is this a bug or an allowed Pascal behavior?

Question

Consider the following Pascal program:

    1  1 PROGRAM MAIN(OUTPUT); VAR F:TEXT; I:INTEGER;
    2  2 BEGIN
    3  2    REWRITE(F);
    4  3    FOR I := 10 TO 30 DO BEGIN
    5  3       WRITELN(   I, ’:’, ’ABCDEFGHIJ’ : I);
    6  3       WRITELN(F, I, ’:’, ’ABCDEFGHIJ’ : I);
    7  2    END;
    8  2    RESET(F);
    9  2    WRITELN(’--------------------’);
   10  3    WHILE NOT EOF(F) DO BEGIN
   11  3       WRITE(F^);
   12  3       GET(F)
   13  3    END
   14  0 END.

The program writes a staircase of ABCDEFGHIJ to the standard output and to a local temporary file, then writes a separator line and copies the local file character by character to the standard output. The expectation is that there will be two copies of the staircase of ABCDEFGHIJ; however, the result on the BESM-6 is

        10:ABCDEFGHIJ
        11: ABCDEFGHIJ
        12:  ABCDEFGHIJ
        13:   ABCDEFGHIJ
        14:    ABCDEFGHIJ
        15:     ABCDEFGHIJ
        16:      ABCDEFGHIJ
        17:       ABCDEFGHIJ
        18:        ABCDEFGHIJ
        19:         ABCDEFGHIJ
        20:          ABCDEFGHIJ
        21:           ABCDEFGHIJ
        22:            ABCDEFGHIJ
        23:             ABCDEFGHIJ
        24:              ABCDEFGHIJ
        25:               ABCDEFGHIJ
        26:                ABCDEFGHIJ
        27:                 ABCDEFGHIJ
        28:                  ABCDEFGHIJ
        29:                   ABCDEFGHIJ
        30:                    ABCDEFGHIJ
--------------------
        10:ABCDEFGHIJ
   15:     ABCDEFGHIJ
    ABCDEFGHIJ
             ABCDEFGHIJ
 CDEFGHIJ
 HIJ

To put it mildly, only the first line is correct, the rest is garbage.

To achieve the expected result, it is necessary to write

   11  3       IF EOLN(F) THEN WRITELN ELSE WRITE(F^);

Or, given that the internal character encoding is almost ASCII, IF F^ = CHR(10) THEN ... also works.

In Programming in Pascal By Nell B. Dale, 1997 (search for eoln, there are only 5 occurrences), it is unclear if explicitly writing an eoln character to the standard output is guaranteed to be functionally equivalent to writeln on all platforms.

Theoretically, even on MS-DOS the internal files, including files of type text, could be treated as binary, and writeln to these files would write just chr(10); the standard output would be treated as text, and writeln to it would write chr(13), chr(10); and for efficiency, there would be no checking for chr(10) appearing in the items being output; thus resulting in an incorrect text file if an equivalent program is run.

Would that be a conforming behavior?

A related issue: when reading from the standard input ("punched cards"), eoln(input) becomes true after 80 of get(input), but at that moment input^ is a space character rather than the line feed. If that is conforming, then the first question would thus be answered in the positive as well.

Answer 1

The ISO 7185 Pascal standard, section 6.4.3.5 "File-types", says (my emphasis):

There shall be a file-type that is denoted by the required structured-type-identifier text. The structure of the type denoted by text shall define an additional sequence-type whose values shall be designated lines. A line shall be a sequence cs ~S(end-of-line), where cs is a sequence of components possessing the char-type, and end-of-line shall represent a special component-value. Any assertion in clause 6 that the end-of-line value is attributed to a variable other than a component of a sequence shall be construed as an assertion that the variable has attributed to it the char-type value space. If l is a line, then no component of l other than l.last shall be an end-of-line. There shall be an implementation-defined subset of the set of char-type values, designated characters prohibited from textfiles; the effect of causing a character in that subset to be attributed to a component of either t.L or t.R for any textfile t shall be implementation-dependent.

A line-sequence, ls, shall be either the empty sequence or the sequence l ~ ls' where l is a line and ls' is a line-sequence.

Every value t of the type denoted by text shall satisfy the following two rules:

a) If t.M = Inspection, then t.L ~ t.R shall be a line-sequence.

b) If t.M = Generation, then t.L ~ t.R shall be ls ~cs, where ls is a line-sequence and cs is a sequence of components possessing the char-type.

NOTE -- 5 In rule b), cs may be considered, especially if it is non-empty, to be a partial line that is being generated. Such a partial line cannot occur during inspection of a fi le. Also, cs does not correspond to t.R, since t.R is the empty sequence if t.M = Generation.

A variable that possesses the type denoted by the required type-identifier text shall be designated a textfile.

So the standard specifically says that end-of-line sequences are implementation dependent, and it doesn't disallow this to differ between standard output, and a file.

It was also always considered good practice in Pascal to never rely on any particular end-of-line encoding, and use eoln/readln/writeln instead. That way, programs would work on different Pascal systems.

So following that practice would also allow for difference between end-of-line representations in different files. And given what kind of OS Pascal was developed first for, I wouldn't be surprised if there are other OS where encoding differs depending on what kind of device the file is on (for example, devices differed by the number of bits a word on the device had).

Finally, "manuals" for Pascal don't matter. The language specification was written by the inventor of Pascal, Niklaus Wirth, and was later turned into the ISO standard quoted. That said, implementations often choose to deviate from that standard, to the displeasure of Wirth, in particular with respect to files and other OS specifics. So "is it allowed Pascal behaviour?" and "does some manual mention this?" are very very different things. Manuals mention many things that are not "allowed" Pascal behaviours.