From: Ali Polatel <polatel@gmail.com>
To: Austin Clements <amdragon@MIT.EDU>, David Bremner <david@tethera.net>
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
Precedence: list

--=-=-=
Content-Transfer-Encoding: quoted-printable

On Tue, 27 Sep 2011 18:46:22 -0400, Austin Clements <amdragon@MIT.EDU> wrot=
e:
> Quoth David Bremner on Sep 27 at  1:59 pm:
> > On Tue, 27 Sep 2011 16:25:58 +0300, Ali Polatel <polatel@gmail.com> 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-----
--=-=-=--