Re: file:read("*n") reference manual entry improvement

[Lorenzo Donati <lorenzodonatibz@...>]

On 26/10/2013 19.59, Francisco Olarte wrote:
> Hi:
> 
> 
>> I am more and more convinced that the real problem is that the
>> implementation has a bug. See the following two cases:
>> input   whas was read by '*n'   returned result
>> 0x.G    0x.                     0
>> 0xG     0x                      nil
> 
> If it's using fscanf, this kind of things are usual. It normally uses
> just one char lookahead and pushes it back on errors, leading to
> bizarre results when errors are deep down, like 1.0E+X, you only
> notice the error when reaching the X, but then you've read a lot of
> chars.
> 

Yep! fscanf is a nasty beast. I assume it is used in Lua codebase to
keep the LOC count down, but I wonder whether it would be better to
avoid it completely and implement "*n" using a custom parsing routine.

After all, all the pieces should be already there: the parser already
knows how to parse numbers in Lua code, and the conversion to a number
is already handled by luaB_tonumber in lbaselib.c.

Maybe it is possbile to factor out the relevant code and reuse it to
avoid fscanf altogether. This would have the nice side effect that the
semantics for "*n" could be specified in a more accurate way.

Maybe it could also be useful for other aspetcts? What would the
drawbacks be?

@Roberto:

Could this be a feasible/useful improvement for Lua 5.3 (or for a Lua
5.2.x - since maybe it can be seen as almost an implementation detail)?

-- Lorenzo

-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments