Re: io:lines() and \0

On Feb 20, 2014, at 18:17 , Francisco Olarte wrote:

Hi Luiz:

On Thu, Feb 20, 2014 at 4:49 PM, Luiz Henrique de Figueiredo
<lhf@tecgraf.puc-rio.br> wrote:
For me fgets(buf, size, file) should be equivalent to a getc loop with
some checkings for size, \n and EOF. And, from what we've seen on this
thread, it seems the libC implementation do it that way.

Not really. See for instance
http://www.opensource.apple.com/source/Libc/Libc-167/stdio.subproj/fgets.c
http://svnweb.freebsd.org/base/head/lib/libc/stdio/fgets.c?revision=249810&view=markup

Your point being? as this example seem to prove my point.

I mean, are this implementations not equivalent to a getc loop on the
same implementations? ( ignoring multithreading issues ) ( I've
changed your links fgets=>fgetc/getc but they both end up calling
__s* stuff, and I'm unable to follow them more ).

This gets is a plain and simple getchar loop:

http://www.opensource.apple.com/source/Libc/Libc-167/stdio.subproj/gets.c

The (latest) glibc has reads the first with getchar (EOF optimization I guess) and the rest with a call to an internal __iogetline.

So everything we saw so far copies everything until end-of-buffer, new-line or end-of-file.

To summarize some standard:

http://pubs.opengroup.org/onlinepubs/009695399/functions/fgets.html

The fgets() function shall read bytes from stream into the array pointed to by s, until n-1 bytes are read, or a <newline> is read and transferred to s, or an end-of-file condition is encountered. The string is then terminated with a null byte.

Upon successful completion, fgets() shall return s. If the stream is at end-of-file, the end-of-file indicator for the stream shall be set and fgets() shall return a null pointer.

I think with my latest patch all corner cases should be handled to successfully transfer the string into a Lua string containing all bytes read and returned by the underlying C library. To adjust the chop behavior (I personally also do not like injecting bytes that where not there, I only wanted to make the argument handling more symmetric) as before change the last line change from.

--l; /* EOF without \n and thus 0-terminated + our \n */

p[l-1] = '\n';

to:

l -= 2;

chop = 0;

What do the Lua authors think about addressing this inconvenience (not to call it a bug) in the current implementation?

René

To me it seems they are optimized equivalents. In particular I notice
they do not use any str* functions, but use mem*, probably for speed
and/or to be nul safe, but they are nul safe like doing it with getc.

In case I did not explain myself. No production libC I've ever looked
at does fgets with a getc loop, I knew this. But all the ones I
remember using give the same result ( as chars stored in the buffer,
not counting buffer overflows, EOF checking and the errors I'm sure
to introduce now ) for 'fgets(buf, size, file)' and
'while((c=getc(f)!='\n' && c!=EOF) *buf++=c; *buf=0;', and that is
what I meant for equivalent.

For 'do it that way' I meant do it so the result the same, I never
expected modern libraries like freebsd or its cousins to use a loop.

Francisco Olarte.