Strange, Calysto should have caught the use of x(malloc|realloc).
Either a bug in Calysto, or I misinterpreted the traces (I did a very
sloppy job analyzing them). Thx for the feedback, I'll try to allocate
more time for the analysis of the next run.
On 7/2/07, Alexandre Julliard <[EMAIL PROTECTED]> wrote:
"Domagoj Babic" <[EMAIL PROTECTED]> writes:
> Possible NULL-ptr deref (vc796):
> @/work/benchmarks/SOURCES/wine-0.9.39/tools/makedep.c:196
> + Ptr p xmalloc-ed (makedep.c:187) dereferenced. Note that although
> xmalloc checks pointer (util.c:31), report(R_FATAL, "msg") does not
> exit, but only reports the msg and returns, so p (NULL) will be
> still dereferenced.
Not a bug, xmalloc does an exit(1).
> *** Analyzing
/work/benchmarks/BINARY/wine_v0.9.39/tools_winebuild_winebuild.bc
> ***
>
> Possible NULL-ptr deref (vc5400):
> @/work/benchmarks/SOURCES/wine-0.9.39/tools/winebuild/import.c:108
> + seems that table->names can be NULL (or unitialized) at this
> line if the test @102 is false, and in the following call chain:
> main -> parse_options -> add_extra_ld_symbol -> add_name
Not a bug, xrealloc never returns NULL.
> Possible NULL-ptr deref (vc5868):
> @/work/benchmarks/SOURCES/wine-0.9.39/tools/winebuild/import.c:362
> + seems that ignore_symbols.names can be NULL if test @359 is true.
Not a bug, names can't be NULL if count isn't 0.
> Possible NULL-ptr deref (vc1013):
> @/work/benchmarks/SOURCES/wine-0.9.39/tools/winegcc/utils.c:118
> + starray_dup (utils.c:136) initializes dup with strarray_alloc().
> strarray_alloc also sets dup->base to NULL. Then strarray_dup calls
> strarray_add (@142), passing it a pointer to dup. If the test in
> strarray_add (@113) fails, the function dereferences dup->base directly.
Not a bug, xrealloc never returns NULL.
--
Alexandre Julliard
[EMAIL PROTECTED]
--
Domagoj Babic
http://www.domagoj.info/
http://www.calysto.org/
