Re: [ANN] Lua 5.3.0 (rc2) now available

[Jean-Luc Jumpertz <jean-luc@...>]

> Le 31 déc. 2014 à 19:19, Roberto Ierusalimschy <roberto@inf.puc-rio.br> a écrit :
> 
>>> There is one warning on Mac OS X (10.10) when compiling in Xcode 6.1.1 with default warnings enabled:
>>> 
>>> /Users/jean-luc/Developpement/lua-5.3.0 - xcode/src/liolib.c:480:16: warning: variable 'c' may be uninitialized when used here [-Wconditional-uninitialized]
>>>  if (!chop && c == '\n')  /* want a newline and have one? */
>>>               ^
>>> /Users/jean-luc/Developpement/lua-5.3.0 - xcode/src/liolib.c:467:8: note: initialize the variable 'c' to silence this warning
>>>  int c;
>>>       ^
>>> This is a false positive, but hard for the compiler to detect that c is always initialized… :-)
>> 
>> It is not that hard: the only branch in the path from the function head
>> to the first assignment to 'c' is obviously false (jump if not (0 <
>> some-non-zero-constant)).  I am afraid that solving this warning with
>> a useless initialization can generate warnings in smarter compilers
>> ("value is never used"). I tried to change the code to make it more
>> "obvious" that 'c' cannot be used uninitialized, but could not find a
>> good solution.
> 

Agreed: the issue is clearly on the compiler’s side. 
Therefore I filled a bug about this incorrect warning in Xcode/Clang.

> You can try this, but in my view it is hardly an improvement...
> 
> --- liolib.c	2014/11/21 12:17:33	2.141
> +++ liolib.c	2014/12/31 18:17:02
> @@ -470,8 +470,11 @@
>     char *buff = luaL_prepbuffer(&b);  /* pre-allocate buffer */
>     int i = 0;
>     l_lockfile(f);  /* no memory errors can happen inside the lock */
> -    while (i < LUAL_BUFFERSIZE && (c = l_getc(f)) != EOF && c != '\n')
> +    do {
> +      if ((c = l_getc(f)) == EOF || c == '\n')
> +        break;
>       buff[i++] = c;
> +    } while (i < LUAL_BUFFERSIZE);
>     l_unlockfile(f);
>     luaL_addsize(&b, i);
>     if (i < LUAL_BUFFERSIZE)
> 
> 
> -- Roberto

I prefer the current version too.

Jean-Luc