Support for use in WASM environments (#192)

[kleisauke]

This PR enables the use of libvips in WebAssembly environments (see #192). It consist of fixing function pointer cast issues,
which can only be detected at runtime (as far as I know). This PR has been tested on a WASM-ported version of the libvips test suite that includes 192 different tests.

It is possible that not all function pointer cast issues are fixed by this PR, as the WASM build does not contain all dependencies supported by libvips. I've managed to support JPEG, PNG, TIFF and WebP images by using libjpeg-turbo, libpng, libtiff and libwebp. EXIF metadata in JPEG files and ICC profile support is also available by using libexif and lcms2. For more details, see #192 (comment).

Here is a brief overview of the related changes within this PR:

• Add vips_area_free_cb (that matches the int (*VipsCallbackFn) (void *a, void *b) signature), in favour of the vips_free callback.
• Deprecate vips_free, just use g_free for non-callback functions and vips_area_free_cb for callback functions (e.g. vips_blob_new or vips_image_set_blob).
• vips_crop needs an adapter function to work properly. This is basically the same as this patch for glib. I've #ifdef'd this change with __EMSCRIPTEN__ since this is a quite a hackish workaround.
• All GThreadFunc callbacks now have the correct signature (i.e. void *(*GThreadFunc) (void *data)).
• Sometimes the last void * parameter was missing from the VipsSListMap2Fn and VipsRegionFillFn callbacks.
• Add a void *user_data parameter to the GCompareFunc and GFunc callback functions. Needed by g_slist_sort and g_slist_foreach. This SO answer might be relevant here.
• Signals using the vips_INT__VOID, g_cclosure_marshal_VOID__POINTER and g_cclosure_marshal_VOID__VOID closures are called with an additional void *data argument.

abi-compliance-checker result:
https://kleisauke.nl/compat_reports/vips/master_to_wasm-function-pointers/compat_report.html

[jcupitt]

This patch is much smaller than I was fearing, phew! It seems straightforward.

I was wondering about the best way to prevent this kind of issue creeping back into libvips in the future. Do you have any thoughts on this? I suppose your set of WASM tests would be a good start.

[kleisauke]

I was counting the amount of lines of the .patch file, and not the amount of changed lines, so the PR arrived much smaller. 😄

Indeed, the WASM tests should be a good start. I just found out that GCC supports a compiler flag called -Wcast-function-type that warns when a function pointer is cast to an incompatible function, which might help to prevent these issues as well. I had an attempt to add this to Travis, see:
master...kleisauke:cast-function-type
https://travis-ci.org/github/kleisauke/libvips/jobs/707609405

It reports some false-postives with the GCompareFunc callback as that is called with an extra user_data argument. But it also found 2 function pointer cast issues that the WASM test suite didn't catch, see:

libvips/tools/vips.c

Lines 111 to 112 in 84d0d5a

	static void *
	list_class( GType type )

static void *
list_class( GType type, void *data )

libvips/libvips/foreign/dzsave.c

Lines 223 to 224 in e728e56

	static void *
	vips_gsf_tree_close( VipsGsfDirectory *tree )

static void *
vips_gsf_tree_close( VipsGsfDirectory *tree, void *a, void *b )

[jcupitt]

I think I fixed those function casts, thanks!

Do you plan a PR with those travis improvements?

[kleisauke]

Great! PR #1716 improves the CI by enabling the -Wcast-function-type warning and updating Ubuntu/GCC to the latest version.