Quoth Ali Polatel on Sep 28 at 10:53 am: > On Tue, 27 Sep 2011 18:46:22 -0400, Austin Clements <amdragon@MIT.EDU> wrote: > > Quoth David Bremner on Sep 27 at 1:59 pm: > > > On Tue, 27 Sep 2011 16:25:58 +0300, Ali Polatel <polatel@gmail.com> wrote: > > > > > > > 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(). > > > > > > 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? > > > > 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. Yes. We could just deal with that (there aren't *that* many API consumers). For binary compatibility, I suppose we could even use symbol versioning. > > 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? Please feel free to write a patch.