[fprint] patches: baby steps: fix some NULL pointer handling

[Bastien Nocera]

Hey Jason,

On Fri, 2015-08-21 at 15:45 -0600, Jason Gerard DeRose wrote:
> As part of helping me understand the libfprint code, I ran scan-build
> and fixed one NULL pointer dereference it reported, which after
> tracing
> that back led to another small fix.
> 
> 0001_fix_NULL_pointer_dereference_in_vfs5001_submit_image.patch
> ===============================================================
> submit_image() in drivers/vfs5001.c checks whether `img` is NULL, but
> was missing a return at the end of the conditional block, so it would
> still go on to dereference the NULL pointer when setting `img
> ->flags`,
> `img->width`, and `img->height`.
> 
> This was caught by scan-build and I confirmed that scan-build no
> longer
> reported an error here after the fix.

This should go in the commit message, not in the email.

> 0002-fpi_img_new_assumes_g_malloc0_succeeds.patch
> =================================================
> fpi_img_new() in img.c assumes that g_malloc0() always succeeds, for
> which there is no guarantee.

There is. GLib's memory allocation code either succeeds, or aborts:
https://developer.gnome.org/glib/stable/glib-Memory-Allocation.html#glib-Memory-Allocation.description

> So if g_malloc0() fails (returns NULL), fpi_img_new() should abort
> and
> return NULL, should not set `img->length`.
> 
> Likewise, fpi_img_new_for_imgdev() should check whether fpi_img_new()
> returns NULL, and if it does, fpi_img_new_for_imgdev() should abort
> and
> return NULL, should not set `img->width`, `img->height`.
> 
> The next step, of course, is making sure all fpi_img_new(),
> fpi_img_new_for_imgdev() consumers check for a NULL return value and
> do
> the right thing.  A task I haven't tackled yet.

So you can drop this patch, and assume that any calls to g_malloc and
variants will succeed.

> Please guide me on preferred patch workflow style!
> ==================================================
> 
> If I haven't submitted these patches in an acceptable form, or if you
> would like me to do it differently next time, please let me know!
> 
> I'm still trying to find my way around here, don't really know the
> best
> approach yet :D

The best would be to attach the patches to bugs filed at https://bugs.freedesktop.org
You can use git-bz:
http://blog.fishsoup.net/2008/11/16/git-bz-bugzilla-subcommand-for-git/
to attach patches to bugzilla, which will make iterating through
patches easier to track.

Cheers