lua-users home
lua-l archive

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


I actually understand why it was not done. That's a pity, sorry for the noise.

On Tue, Mar 14, 2017 at 12:43 AM, Igor Ehrlich <iehrlich@iponweb.net> wrote:
I'll just cautiously metion that the analyzer warning is 100% correct from the language perspective. Should we possibly consider fixing it in the interpreter? The fix seems to be _rather_ straightforward, without any possibly negative performance effects.

On Tue, Mar 14, 2017 at 12:32 AM, Jerry Jacobs <jerryjacobs1989@gmail.com> wrote:
It hasn’t anything todo with the incorrectness of luaL_error. But with the analyzer choking on a potential NULL pointer deference. The function os_date returns an int. So does luaL_error return an int. On other places return luaL_error(“”) is implemented, except for this place. Which would be:

  if (stm == NULL)  /* invalid date? *
    return luaL_error(L, "time result cannot be represented in this installation”);

Its only necessary for the analyzer to shut its mouth, the code is 100% correct.

> On 13 Mar 2017, at 22:25, Igor Ehrlich <iehrlich@iponweb.net> wrote:
>
> I believe the proper way is to mark luaL_error with a no-return specifier? Something like GCC's "__attribute__((noreturn))" would possibly do the trick. Also, this the actual syntactic _expression_ for "functions using setjmp/longjmp".
>
> On Mon, Mar 13, 2017 at 11:54 PM, Jerry Jacobs <jerryjacobs1989@gmail.com> wrote:
> I’m using lua 5.3 in a project and clang static analyzer (scan-build) complained about a potential NULL pointer deference in OS lib (loslib.c). The analyzer doesn’t know luaL_error uses setjmp/longjmp and it has its full right to complain. The os_date C function contains this code:
>
> stm = l_gmtime(&t, &tmr);
>
> ~~~ snip ~~~
>
>   if (stm == NULL)  /* invalid date? */
>     luaL_error(L, "time result cannot be represented in this installation”);
>
> ~~~ snip ~~~
>
> problem “passing NULL pointer” ->  setallfields(L, stm);
>
> A simple solution would be just doing a return luaL_error which silences this false-positive.
>
> Kind regards,
> Jerry Jacobs
>
>
>
> --
> Best regards,
> Igor A. Ehrlich





--
Best regards,
Igor A. Ehrlich



--
Best regards,
Igor A. Ehrlich