Re: Strange io.read behaviour

[Tim Channon <tc@...>]

Patrick Donnelly wrote:

> 
> The second call to f:read("*n") skips all the whitespace "\r\n" (moves
> the file position) trying to find a number to read. It fails because
> "astring" is not a number. Thus, the next time you read a line you get
> "astring".
> 

If that was the case it might be acceptable but it isn't and after some
investigation I consider the behaviour a defect. It is inconsistent and
not useful.

The killer is loss of data.

If you modify astring to 99.eastring it fatally falls over. Returns
nothing but then a read of string returns astring, the 99. has been lost.

The cause in my view is poor readahead handling.

Both "*l" and "*n" should if the found terminator is a line end, consume
the line end. In the case of "*n" done when reading the last number on a
line.
At the moment *n consumes a line end, tries to read, falls over and does
not restore the previous state. This is a classic single readahead
problem. If it backed up two tokens it would be acceptable, behaviour
would be consistent, *n would refuse to consume more than a line end.

That still poses problems though. What if the following line contains
what looks like a number? The logic turns bad the other way. You dare
not use *n but *l would return nothing, needing a second call.

The fix is likely to be just consume any trailing found line end.
Alternatively *n should refuse to consume line ends, the programmer did
say read a number and that is literally all it does, no guessing nor
assumptions. In this instance it becomes easy to manually handle line
ends using read(1)

The effect of the current behaviour is precluding very simple handling
of numbers and strings in a file without needing logic and foreknowledge
about the file contents.