lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Hi Francisco,

On Feb 20, 2014, at 13:26 , Francisco Olarte wrote:

Hi René;

On Wed, Feb 19, 2014 at 5:20 PM, René Rebe <rene@exactcode.de> wrote:
--- lua-5.2.3/src/liolib.c 2013-04-12 18:48:47.000000000 +0000
+++ lua-5.2.3-patched/src/liolib.c 2014-01-22 05:47:35.331037586 +0000
@@ -378,7 +378,13 @@
      luaL_pushresult(&b);  /* close buffer */
      return (lua_rawlen(L, -1) > 0);  /* check whether read something */
    }
-    l = strlen(p);
+    {
+      char t = p[LUAL_BUFFERSIZE - 1]; /* scan for line end */
+      p[LUAL_BUFFERSIZE - 1] = '\n';
+      l = (char*)memchr(p, '\n', LUAL_BUFFERSIZE) - p + 1;
+      p[LUAL_BUFFERSIZE - 1] = t;
+      if (l == LUAL_BUFFERSIZE && t == 0) --l; /* was 0-terminated */
+    }
    if (l == 0 || p[l-1] != '\n')
      luaL_addsize(&b, l);
    else {

Have you done border case testing? It seems to me you may get false
positives on '\n' scanning if you read a last file line which hasn't
got a '\n' and there is a stray '\n' in the space returned by
lual_prepbuf ( which does not document returned space initialization
). after the line. ( I think it can be testing by having a 'memset(p,
' \n', LUAL_BUFFERSIZE) after each prepbuf in the test and making it
read a file with a single no newline char, say an A in it,  but I
would need more analysis to assert it. It seems in this case buffer
will end up with "A\0\n\n\n....", memchr will end up at buf[2], l
would be 3, and you'll end up transforming "A" to "A\0\n". ).

Yes, that patch was not perfect, see my new post from today.

René

-- 
 ExactCODE GmbH, Jaegerstr. 67, DE-10117 Berlin
 http://exactcode.com | http://exactscan.com | http://ocrkit.com | http://t2-project.org | http://rene.rebe.de