From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id z1rJNKG5AF8oOgAA0tVLHw (envelope-from ) for ; Sat, 04 Jul 2020 17:17:21 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id 0OAeMKG5AF/JPAAAB5/wlQ (envelope-from ) for ; Sat, 04 Jul 2020 17:17:21 +0000 Received: from mail.notmuchmail.org (nmbug.tethera.net [144.217.243.247]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 5CF399409D3 for ; Sat, 4 Jul 2020 17:17:20 +0000 (UTC) Received: from [144.217.243.247] (localhost [127.0.0.1]) by mail.notmuchmail.org (Postfix) with ESMTP id A90B51FA20; Sat, 4 Jul 2020 13:17:13 -0400 (EDT) Received: from fethera.tethera.net (fethera.tethera.net [IPv6:2607:5300:60:c5::1]) by mail.notmuchmail.org (Postfix) with ESMTP id 348DB1F709 for ; Sat, 4 Jul 2020 13:17:11 -0400 (EDT) Received: by fethera.tethera.net (Postfix, from userid 1001) id 1AD88613B0; Sat, 4 Jul 2020 13:17:11 -0400 (EDT) Received: (nullmailer pid 3732948 invoked by uid 1000); Sat, 04 Jul 2020 17:17:09 -0000 From: David Bremner To: Floris Bruynooghe , notmuch@notmuchmail.org Subject: Re: [PATCH 2/4] lib: catch error from closed db in n_m_get_message_id In-Reply-To: <87h7unxp1j.fsf@powell.devork.be> References: <20200630011411.612552-1-david@tethera.net> <20200630011411.612552-3-david@tethera.net> <87h7unxp1j.fsf@powell.devork.be> Date: Sat, 04 Jul 2020 14:17:09 -0300 Message-ID: <87eeprkxnu.fsf@tethera.net> MIME-Version: 1.0 Message-ID-Hash: EXKHULIU2HMK75ZQ5N2BGNBJRKVWBPG2 X-Message-ID-Hash: EXKHULIU2HMK75ZQ5N2BGNBJRKVWBPG2 X-MailFrom: david@tethera.net X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-notmuch.notmuchmail.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header X-Mailman-Version: 3.2.1 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of notmuch-bounces@notmuchmail.org designates 144.217.243.247 as permitted sender) smtp.mailfrom=notmuch-bounces@notmuchmail.org X-Spam-Score: 0.53 X-TUID: vvLs5QDGzKeO Floris Bruynooghe writes: >> - * This function will not return NULL since Notmuch ensures that every >> - * message has a unique message ID, (Notmuch will generate an ID for a >> - * message if the original file does not contain one). >> + * This function will return NULL if triggers an unhandled Xapian >> + * exception. > How much of a departure from the existing API is this? Will this be > possible with all functions? I had a quick look and tried some other > functions that don't return notmuch_status_t: It's upward compatible in that any code which crashes because it was not expecting a NULL pointer, will already be crashing in the same circumstances because of an uncaught exception / call to abort. > notmuch_database_get_version currently returns and unsigned int and > segfaults on use with a closed db. Yes, the ones without a proper status value are going to be a bit work. In the next series I just posted [1], I started providing status value returning version (see notmuch_message_get_flag_st). We've been through a few of these migrations and it has not been too painful. > I wonder if a backwards-compatible errno-style API could work, > notmuch_last_status(notmuch_database_t* database) or so. This kind of > thing is probably easy to adopt in bindings but harder for direct users > of the API. It's also an extra API call for everything that doesn't > return notmuch_status_t. But I'll leave the judgement to you, I'm not > as experienced with the API. I think my main objection to this is that there is no out-of-band value to tell the caller they need to check errno. So basically every call to to one of the relevant functions would need be followed by a call to checking the error number. I don't think that's less work than switching to a new API. Of course it's less work for me, and we already sort of made that choice with notmuch_database_status_string. In that case it was a matter of changing the entire API. Here we're talking about 10 functions, and I'm not sure if they all need to be changed. For example several of the notmuch_foo_valid functions just check pointers for being NULL and can't generate I/O or exceptions. d [1]: id:20200704151805.3717715-1-david@tethera.net