Re: Quiteing clang static analyzer

[Jerry Jacobs <jerryjacobs1989@...>]

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