From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id BA800431FD0 for ; Wed, 28 Sep 2011 00:53:14 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.789 X-Spam-Level: X-Spam-Status: No, score=-0.789 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_MIME_NO_TEXT=0.01] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mGdJybCuofH for ; Wed, 28 Sep 2011 00:53:14 -0700 (PDT) Received: from mail-bw0-f53.google.com (mail-bw0-f53.google.com [209.85.214.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id 233C3431FB6 for ; Wed, 28 Sep 2011 00:53:14 -0700 (PDT) Received: by bkbzt12 with SMTP id zt12so9148977bkb.26 for ; Wed, 28 Sep 2011 00:53:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-type; bh=pTGlSshghy7gaF127lt1GTcHej3KMJ9sz86TrBMm600=; b=oBEN65WOoczRxQM1+oxKZg335fnADzgM2IITj6ap2eMoMEi7fAkC7dJ5e+yPhe1Nas xCkDLTXBzABlgT/+yEUjPMno673KOBmyFxxADIutHiv/3MmKzzY0MEVRya68oz8zrWf2 Yv1ABe/k9TuQBr6+848UfbPglMQ/6Ymv7WsUQ= Received: by 10.204.154.194 with SMTP id p2mr5802996bkw.56.1317196391424; Wed, 28 Sep 2011 00:53:11 -0700 (PDT) Received: from localhost ([88.251.189.177]) by mx.google.com with ESMTPS id j16sm21766924bks.3.2011.09.28.00.53.09 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Sep 2011 00:53:10 -0700 (PDT) From: Ali Polatel To: Austin Clements , David Bremner Subject: Re: Concerns regarding some library functions In-Reply-To: <20110927224622.GR17905@mit.edu> References: <871uv2unfd.fsf@gmail.com> <87fwjhx6p5.fsf@convex-new.cs.unb.ca> <20110927224622.GR17905@mit.edu> User-Agent: Notmuch/0.8-39-gdd7cb35 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu) Date: Wed, 28 Sep 2011 10:53:02 +0300 Message-ID: <877h4tyug1.fsf@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Cc: notmuch@notmuchmail.org X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 07:53:14 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable On Tue, 27 Sep 2011 18:46:22 -0400, Austin Clements wrot= e: > Quoth David Bremner on Sep 27 at 1:59 pm: > > On Tue, 27 Sep 2011 16:25:58 +0300, Ali Polatel wro= te: > >=20 > > > The problem with their design is NULL return may both mean an error > > > condition and "message not found". However, we already have a similar > > > function which does not have such a flaw, namely notmuch_database_add= _message(). > >=20 > > So, I take there is no way to distinguish those two outcomes? That does > > sound bad. Looking at the code for notmuch-new, it looks like the return > > value of notmuch_database_find_message_by_filename is used without > > checking it for NULL. Austin, can you comment on that at all? >=20 > I'd be happy to distinguish these outcomes. I did > notmuch_database_find_message_by_filename the way I did only to be > consistent with notmuch_database_find_message. Since ndfmbf isn't > entrenched yet, now is a good time to change it. What about notmuch_database_find_message()? If we leave it as it is, this will lead to inconsistency and if we change it, we need to think about API breakage issues. > The call in notmuch-new should check the return, though if it can't > find the message at that point, something has gone terribly wrong. > Segfaulting is never the answer, though. Indeed, just not to step on each other's feet, are you going to write a patch or shall I start writing one? -alip --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk6C0mAACgkQQU4yORhF8iD/IQCgl4jc5BGVFauAIvnSuhV+4DIX cWMAoMsEkiq4IPfEpuKEyIFj7oNOLWGo =vZa4 -----END PGP SIGNATURE----- --=-=-=--