Read

│ Deutsch (de) │ English (en) │

The procedures read and readLn retrieve data from a text file (such as input, the command line interface, or any file on disk). They are defined as part of the Pascal programming language. Everyone can expect them to work no matter which compiler has been used.

In property definitions the reserved word read is used to direct read access. This article deals with the procedures read and readLn. See object and related articles for the occurrence of read in the context of properties.

Behavior

Signature

Read as well as readLn share almost the same identical formal signature. However a formal signature is omitted here, since you can not write their signatures in Pascal. Therefore a description follows:

As an optional first parameter a text variable can be specified where data are read from. Read is additionally capable of reading from a typed file variable (file of recordType).

If no source is specified, input is assumed. Thereafter any number of variables can be specified, but at least one has to be present. They have to be either char, integer, real, or string. If you have specified a typed file as the source, all variables have to be of the file’s underlying base type.

Earlier versions of FPC also allowed reading variables of the type PChar. This has been removed, since no buffer checking is possible with those. In the case of typed files as source, only variables of the file’s record type can be specified.

Execution

Calling read/readLn will place the read (and possibly accordingly interpreted) values to the given variables.

The order of variables matters. For instance, when the following program:

program readDemo(input, output, stderr);
var
	i: integer;
	c: char;
begin
	readLn(i, c);
end.

is supplied with:

42 x

everything is fine.

i will become 42 and c will become 'x'. But the reverse input order

x 42

will yield a run-time error (in this case RTE 106).

Once data are read and stored, they are “consumed”, thus cannot be retrieved otherwise, but via the variables only. However, data are read up to the variable’s size limits. E. g. a fixed length string[24] will stop reading beyond the 24th character.

Leading blanks in front of numeric types are skipped.

If the source file is not open, the RTE 103 “file not open”, RTE 6 “invalid file handle” (for input in a non-ISO compiler mode) will stop the program. These RTE may be converted to an eInOutError exception if the sysUtils unit is included (e. g. via a uses-clause).

If the source file is open, but no data is available, possibly because the end of file has already been reached, default values for the remaining variables are loaded.

Interpretation

Read and readLn are so powerful, because they interpret given data. For instance, a readLn storing an integer does not expect the binary value to be entered, but their decimal representation with ASCII numerals suffices (e. g. 42 instead of * [asterisk has the numeric value 42]).

While char and string can be stored (sort of) directly, the numeric types integer and real are converted following certain rules. The rules are those, you normally write literals of such types within your (Standard) Pascal source code. However, some compilers’ read implementation (here FPC) allow additional formats:

An integer’s hexadecimal base can be indicated by prepending 0x, or just x (case insensitive) instead of the usual $ (dollar sign).

Difference between read and readLn

ReadLn will in contrast to read consume a trailing line feed. It is discarded and does not have any influence on how to save supplied data. The read line ending is platform-independent. A line ending typical for Windows-platforms will be read and does not pose a problem, even if the program is run on Linux or any other platform.

Note, the notion of “line” applies only for text files. Functions like eoLn and readLn only work on such files. In consequence readLn can not be used on typed files (file of recordType variables).

Production usage

Read and readLn have a major drawback in that they expect the user to supply data in a given order. If users do not comply a run-time error will terminate the program.

This is quite unsatisfactory, since a run-time error number won’t enlighten the end user. You usually want to design your error messages in a way the user is capable in correcting her behavior. When reading ordinal types one can make use of the val procedure.

program readNumbers(input, output, stderr);

{$modeSwitch out+}

{**
	reads an integer from input
	
	\param destination the variable to store the read value in
	\returns true if reading was successful
	
	This function will inform the user about any mistakes.
*}
function readLnInteger(out destination: integer): longbool;
var
	/// temporarily stores input string
	userInput: ansistring;
	/// stores return code of val
	errorPosition: valSInt;
begin
	readLn(userInput);
	
	val(userInput, destination, errorPosition);
	
	// val is successful, if no character caused problems
	readLnInteger := errorPosition = 0;
	
	// tell the user, what went wrong
	if not readLnInteger then
	begin
		if length(userInput) < 1 then
		begin
			writeLn('Error: There was no input.');
		end
		else
		begin
			writeLn('Error: Could not parse your input as an integer. Your input was:');
			writeLn(userInput);
			
			// set an arrow right below
			// the character causing troubles
			writeLn(space(errorPosition-1), '⇡');
			writeLn('The character with an arrow underneath caused the troubles.');
			
			if length(userInput) > bitSizeOf(nativeInt) then
			begin
				writeLn('Maybe your value is too large.');
			end;
		end;
	end;
end;

{ === M A I N ================================================ }
var
	EOI: Boolean;

function endOfInput(): Boolean;
begin
	EOI := system.eof();
	endOfInput := EOI;
end;

var
	i: integer;

begin
	repeat
	begin
		writeLn('Enter an integer:');
	end
	{$push}
	{$boolEval off} // lazy evaluation [until or_else is supported]
	until endOfInput() or readLnInteger(i) or endOfInput();
	{$pop}
	
	if EOI then
	begin
		halt(1);
	end;
	
	writeLn('Excellent choice!');
end.

Beware, it is necessary to check, whether the end of file has been reached before attempting to read data. The text file input may not be open. Unlike readLn no default value is loaded. Hence it is imperative to check val’s code value in order to determine whether the destination variable v now has a legit value.

Of course, it would be even better to catch wrong key strokes right when they are made, but this is not possible when utilizing read or readLn.

  Note: Therefore the main application of read or readLn is non-interactive programs reading (generated) data files.

Nevertheless, if the convenient interpretation functionality is desired, without having a file open, the procedure system.readStr can be used to do so.

See also

• system.read and system.readLn
• Why use Pascal, § “the readLn and writeLn effect”
• Secure programming regarding how to properly treat input
• write performing the opposite action