Re: io:lines() and \0

[Francisco Olarte <folarte@...>]

Hi René

On Sat, Feb 22, 2014 at 8:20 PM, René Rebe <rene@exactcode.de> wrote:

> While working on the source I already had the "feeling" the function
> should only continue reading on a full buffer, not using the current
> "if last char is not \n" check, but could not imagine a case it fails.
> Thank you for this example!

Well, you need the last-char is not \n test always, as you need to
distinguish the split-line with the line-which-just-fills-a buffer (
82 buf, 80 chars, 1 newnile, one null ). Once you have it, you can
normally let it spin around for easier code ( on text files ), as the
only documented stop conditions are \n and EOF, and EOF is going to
give you the fgets=null on next loop. Once you test for '\n' you need
the ==0 tests ( which you could use to optimize, if you get it on
first iter you where at the end of a file with a properly newline
terminated last line or an empty file, but been a just-once case does
not matter ( even if it provokes the need to test for result length,
which I find fugly too, with old age I've come to dislike this sort of
things and use explciit counts / state vars ) ). What will be really
perverse would be to optimize a short newline less line to mean eof
and mark the handle as such :->  ( it would be correct for text files
).

> (I wish we could just simple fix this 2 bugs, ... :-/)

They are not bugs. Do like me, use a language with a broader
definition of text files, patch lua ( if you are going to patch it for
yourself and are on a glibc systems try the unlocked getc besides your
memset versions, it may be faster on modern machines ( extra read /
writes fsck your caches ) ).

I, personally, will do a glibcio with unlocked versions patching the
original and investigate how to make *.io ( do not know exactly which
table to use ) point to it after loading it first thing in my code, or
just leave it at gio.

Francisco Olarte.