Re: Potential Null Pointer Dereference in resizebox method from lauxlib.c

[Andrew Gierth <andrew@...>]

>>>>> "Yongchao" == Yongchao Wang <chaowyc@gmail.com> writes:

 Yongchao> As a result, I detected three more null pointer dereferences
 Yongchao> that are similar in nature (I will present them later).

These are similar in the sense that they are also not bugs.

 Yongchao>    RanState *state = (RanState *)lua_touserdata(L, lua_upvalueindex(1));

Here, and in the other cases where upvalues are involved, the upvalue is
known to be of the correct type (because the code that created it
ensured that) and therefore lua_touserdata does not return NULL. (The
only way to make it return null would be to modify the upvalue using the
debug library, which is explicitly documented as being able to cause
crashes - much like using a debugger to change the value of a pointer
variable in C to NULL could cause a crash too, regardless of any checks
the program did.)

 Yongchao> 2. `lua_topointer` is called at lstrlib.c:1334 and the return
 Yongchao> value is checked at lstrlib.c:1336

 Yongchao> static int str_format (lua_State *L) {
 Yongchao> ...
 Yongchao> case 'p': {
 Yongchao>    const void *p = lua_topointer(L, arg); // line 1334
 Yongchao>    checkformat(L, form, L_FMTFLAGSC, 0);
 Yongchao>    if (p == NULL) { /* avoid calling 'printf' with argument NULL */ // line
 Yongchao> 1336

This is explicitly checked for NULL because it is printing a value
passed in from the user, e.g. string.format("%p", true).

-- 
Andrew.