Read

│ Deutsch (de) │ English (en) │

The procedures read and readLn retrieve a date from a text file. 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.

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 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 compiler’s 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
*}
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;
	
	if not readLnInteger then
	begin
		// set an arrow right below
		// the character causing troubles
		writeLn(space(errorPosition-1), '⇡');
	end;
end;

{ === M A I N ================================================ }
var
	i: integer;
begin
	repeat
	begin
		writeLn('Enter an integer:');
	end
	{$push}
	{$boolEval off} // lazy evaluation
	until eof() or readLnInteger(i);
	{$pop}
	
	if eof() then
	begin
		halt(1);
	end
end.

Beware, it is necessary to check for end of file. Unlike readLn no default value is loaded.

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