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
