Did compilers ever give error messages without line numbers?

Question

I'm having an argument with my friend, who told me that when she was learning programming in the 1980s, the compiler gave errors without line numbers.

I'm pretty sure that compilers have always given a line number (or card number) for errors, going all the way back to the 1960s, not matter what language (Fortran, COBOL, Algol, whatever), especially considering that even back then, compilers supported programs that were thousands or tens of thousands of lines long.

This kind of sounds like a "you kids today have it so easy.... in my day..." type of tall tale.

Answer 1

In some sense, the question is ill-defined. Error messages themselves often did not need to include line numbers, because the typical paper-to-paper compile-and-run cycle would already be producing a (line-numbered) listing.

Compile-time error messages would then appear underneath the erroneous line, often with an arrow or similar mark pointing to the character where the error was detected.

The line number could be discovered from the listing, but the error message did not itself mention the line number.

Answer 2

There is an online copy of a paper titled Compiler Error Messages Considered Unhelpful by Becker et al.

Partway through the paper, there is a discussion of error messages in FORTRAN, Logo, Basic, and Pascal. These are languages that were extensively used for teaching programming in the 1960s and 1970s. It doesn't get down to line numbers, but it does deal with localising errors based on error messages. There are several languages where unbalanced parentheses or brackets aren't going to be detected until the end of the source file. A line number here is not very helpful for localising the error.

Many early versions of FORTRAN did not interpret columns 73 through 80 of the source program. They were generally used for including a card number (in effect, a line number) on every line. Any error reporting scheme that included these columns would end up reporting line numbers, provided the author had used them for this purpose.

Answer 3

Here's a slightly truncated job output from an IBM 1130 Fortran compiler, c.1968, as run in an emulator:

// JOB
// FOR
*ONE WORD INTEGERS
*LIST ALL
*IOCS(1132 PRINTER)
      DO 100 I=1,185,5
      WRITE(3,90) I, I
      FORMAT(1X,I8,I8)
  100 CONTINUE
      CALL EXIT
      END
VARIABLE ALLOCATIONS
     I(I )=0000

INVALID STATEMENTS
 C 46 ERROR AT STATEMENT NUMBER 00000+002
 C 28 ERROR AT STATEMENT NUMBER 00000+003

COMPILATION DISCONTINUED

// XEQ

M 12 EXECUTION SUPPRESSED

The FORMAT declaration has no line number: it should be 90. Had I put in line numbers before 100, it would have reported the highest number seen before the error.

The errors are:

• C46 — FORMAT statement number missing or incorrect in a READ or WRITE statement.

• C28 — FORMAT statement without statement number.

Another language that's not great about reporting errors is PostScript. While it's interpreted, it will only report stream position of the error, and a display of the top items on the stack. This is fairly nearly useless for all but the very simplest code.

Answer 4

Did they? Yes. They do even today. To wit:

% cat bad.lsp

(defun triple (X)
  "Compute three times X."  ; Inline comments can
  (* 3 X))                  ; be placed here.

;;
;; Negate the sign of a number
;;

(defun negate (X)
  "Negate the value of X."  ; This is a documentation string.
  ((- X))

;; main

(format t "hello world ~a~%" (triple (negate 2)))

I've even left included comments in subtly broken example so it is easy to understand. Now when you go compile it with GNU Common Lisp compiler:

% gcl -compile bad.lsp

Compiling bad.lsp.


Error: END-OF-FILE :STREAM #<input stream #p"bad.lsp">
Fast links are on: do (si::use-fast-links nil) for debugging
Signalled by APPLY.

%

Granted gcl-2.6.12 on my Debian Buster system has last been updated in 2006, with no real source changes since 2002, but still much more recent than 1980s.

(BTW Fix is trivial in this example, just remove the erroneous parenthesis. It might be nontrivial to find correct one if the program was not so trivial as this one)

Also note that few languages popular today (like SQL, RegEx etc) do not even have a concept of line numbers (even if users often split them to multiple lines for readability). True, often they are interpreted, but in some cases they are compiled, and you won't be helped much by knowing that the error is in the only line of your split-into-hundreds-lines-with-comments-regex.

Answer 5

Here is an actual listing from the FORTRAN compiler #XFAM, running on an ICL 1903A in December 1973 under a single-programming operator's exec.

This part of the listing is little more than what was on the cards. You'll notice the total absence of line numbers. I therefore submit, but cannot prove it since my code had no errors :-) that error messages would have not referenced a line number.

So, there we have it: (almost) proof that not all compilers user line numbers in error messages.

Answer 6

The code generated by Turbo Pascal 2.0 and 3.0 (and likely 1.0) would flag runtime errors not with a line number, but with the address of the generated machine code that triggered the fault. This might not sound very useful, except that Turbo Pascal generated machine code directly from source code, and included a "find runtime error" function that prompted a user to type in a machine-code address and would then run the compiler without sending output anywhere, counting how many bytes were written. When the proper number of bytes were written, the process would stop and open up the editor at whatever part of the program was being compiled at that moment.

Answer 7

Even today, when using languages where use of an identifier will implicitly import it, misspelling an identifier will often cause a linker error which supplies the names of the identifier and the file in which it was identified, but gives no clue as to where within the file it was identified. While a linker error isn't an error in the compiler per se, it would be an error produced by the build system.

Additionally, there may be some cases where a compiler generates assembly code and the assembler generates an error without having any reference to the source line available. The most common situation where I've seen that is where a compiler estimates that a branch will be within range to avoid a springboard, but the assembled code ends up being slightly larger than expected. That would ideally never happen with a good compiler, but compiler designers would have to trade off the possibility of such errors with the cost of needless springboards.