Re: [pdf-devel] Task FS#110

[Aleksander Morgado]

Hi Gustavo,

> I've been looking at the task and I found that, even for those problems
> regarding null-dereferencing or uninitialized variables using, most
> aren't problems at all.
> 

That happens a lot yes :-/

> For example:
> 
> utils/pdf-reader.c, stated as "Uninitialized return value" doesn't have
> a problem, since variable *read_mode needs to be true and false at the
> same time in order to make that happen.
> 

You mean utils/pdf-filter.c, right?

It's a pretty weird thing that Clang didn' catch that, interesting.
Anyway, I just initialized the 'stm' variable to NULL and that should
fix it. The change is already in trunk:
http://bzr.savannah.gnu.org/lh/pdf/libgnupdf/trunk/revision/935

> Is there a way to report this, so that future contributors don't need to
> spend time trying to figure it out again?

That is a good question. I've used other static analysis tools that
allow marking issues to be ignored through a web-based interface, but
it's not the case here, reports are static HTML. Maybe there's a way of
generating a file with things to ignore by clang? Something like
valgrind's suppressions file... would be good to check that.

> 
> Also send a tiny patch to a tiny problem that seemed real to me... 
> 

Thanks for that patch, it really is a bug being fixed (using a variable
without initializing it). But I don't think we should apply it right
now, as I already refactored pdf-filereader in a not-yet-merged branch,
also removing that issue. See:
http://bazaar.launchpad.net/~aleksander-m/gnupdf/fsys-api/view/head:/utils/pdf-filereader.c#L540
That branch should hit trunk soon.

Thanks for the patch anyway! :-)

Cheers,

-- 
Aleksander

signature.asc
Description: This is a digitally signed message part