notmuch/lib, branch 0.31.4 thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=0.31.4 2021-02-15T20:43:50Z fix build failure with glib 2.67 2021-02-15T20:43:50Z David Bremner david@tethera.net 2021-02-15T20:43:50Z urn:sha1:6db8b422d91a75b7c16f013f10f41d1109ce5866 Based on a patch from Michael J Gruber [1]. As of glib 2.67 (more specifically [2]), including "gmime-extra.h" inside an extern "C" block causes build failures, because glib is using C++ features. Observing that "gmime-extra.h" is no longer needed in notmuch-private.h, which can simply delete that include, but we have to correspondingly move the includes which might include it (in particular crypto.h) out of the extern "C" block also. This seems less fragile than only moving gmime-extra, and relying on preprocessor sentinels to keep the deeper includes from happening. Move to the include to the outside of the extern block. [1]: id:aee618a3d41f7889a7449aa16893e992325a909a.1613055071.git.git@grubix.eu [2]: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1715 lib/config: delay setting talloc destructor 2020-12-23T23:48:43Z David Bremner david@tethera.net 2020-08-08T14:16:47Z urn:sha1:27020503402af546d9d3017bb4a6346497c85d09 If Xapian has thrown an exception, it is not safe to invoke the destructor when freeing the list struct. (cherry picked from commit 43ba5ed7eca6e9f6433b8c2c2a9d834d4101b92a) lib/config: don't set destructor until iterator is initialized. 2020-10-30T00:13:01Z David Bremner david@tethera.net 2020-10-30T00:13:01Z urn:sha1:582e919e2769bd99064b997b05e1601ffcfe9a98 As diagnosed by Olivier Taïbi in id:20201027100916.emry3k2wujod4xnl@galois.lan, if an exception is thrown while the initialization is happening (e.g. if the function is called on a closed database), then the destructor is (sometimes) invoked on an uninitialized Xapian object. Solve the problem by moving the setting of the destructor until after the placement new successfully completes. It is conceivable this might cause a memory leak, but that seems preferable to crashing, and in any case, there seems to be nothing better to be done if the initialization is failing things are in an undefined state by definition. Fix typos 2020-08-10T00:14:36Z Jonas Bernoulli jonas@bernoul.li 2020-08-08T11:49:55Z urn:sha1:6c84dee53193a78cf797b44d3febcc14488ea6b1 emacs: Use makefile-gmake-mode in Makefile*s 2020-08-10T00:14:36Z Jonas Bernoulli jonas@bernoul.li 2020-08-08T11:49:49Z urn:sha1:c4541353765dec837c1c2f912b1bf6661827429c Use `makefile-gmake-mode' instead of `makefile-mode' because the former also highlights ifdef et al. while the latter does not. "./Makefile.global" and one "Makefile.local" failed to specify any major mode at all but doing so is necessary because Emacs does not automatically figure out that these are Makefiles (of any flavor). test: regression test for traversing config list with closed db 2020-08-04T00:03:43Z David Bremner david@tethera.net 2020-08-01T12:26:02Z urn:sha1:e3f88436b7850ac04468416223e136eaaca4aee3 Also mention error return in API docs lib: fix return value for n_directory_delete 2020-08-03T23:59:06Z David Bremner david@tethera.net 2020-08-01T12:25:59Z urn:sha1:f4f5db0f1a6e89f56bfd73f8517c1cac7af20290 Falling out of the catch meant the error return was lost lib: catch exceptions in n_directory_get_child_files 2020-08-03T23:56:09Z David Bremner david@tethera.net 2020-08-01T12:25:57Z urn:sha1:337665e26a4f0bb0e24a9160f45faf444032bf5d Also clarify API in error case. lib: catch exceptions in n_directory_get_child_directories 2020-08-03T23:53:04Z David Bremner david@tethera.net 2020-08-01T12:25:55Z urn:sha1:9668583a49e9fe2e39844ceaab20779c9444ba8f Also clarify API in error case. lib: return NULL from n_d_get_default_indexopts on error 2020-08-03T23:45:58Z David Bremner david@tethera.net 2020-08-01T12:25:50Z urn:sha1:31dab9b1cd66c7f285fe86021f66940f679325d4 This is a rare and probably serious programming error, so better not to silently return a default value.