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 266C4431FD0 for ; Thu, 29 Sep 2011 07:49:10 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7] 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 3BHd+NCIC4h7 for ; Thu, 29 Sep 2011 07:49:09 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (DMZ-MAILSEC-SCANNER-8.MIT.EDU [18.7.68.37]) by olra.theworths.org (Postfix) with ESMTP id 984F6431FB6 for ; Thu, 29 Sep 2011 07:49:09 -0700 (PDT) X-AuditID: 12074425-b7f116d0000008fe-c2-4e848564eca6 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 42.CF.02302.465848E4; Thu, 29 Sep 2011 10:49:09 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id p8TEn88i010557; Thu, 29 Sep 2011 10:49:08 -0400 Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91]) (authenticated bits=0) (User authenticated as amdragon@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p8TEn6E5016066 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 29 Sep 2011 10:49:07 -0400 (EDT) Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.72) (envelope-from ) id 1R9HxR-0006p7-Ti; Thu, 29 Sep 2011 10:51:29 -0400 Date: Thu, 29 Sep 2011 10:51:29 -0400 From: Austin Clements To: Ali Polatel Subject: Re: Concerns regarding some library functions Message-ID: <20110929145129.GB17905@mit.edu> References: <871uv2unfd.fsf@gmail.com> <87fwjhx6p5.fsf@convex-new.cs.unb.ca> <20110927224622.GR17905@mit.edu> <877h4tyug1.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <877h4tyug1.fsf@gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphleLIzCtJLcpLzFFi42IRYrdT101tbfEz6P7NYXGjtZvR4vrNmcwW fXu+sTowe+ycdZfd49mqW8weWw69Zw5gjuKySUnNySxLLdK3S+DK+PLlIUvBI96Klb93sjcw fuDqYuTkkBAwkWh7/YIVwhaTuHBvPVsXIxeHkMA+Rom3f/vYQRJCAhsYJWbttoVInGSS+LXg DzOEs4RRYtvtu0wgVSwCqhILJuwE62AT0JDYtn85YxcjB4eIgLJE3/ZEkDCzgJ3Eke9dYGFh ATOJVwvlQMK8AjoSTW+mMUKM7GOUuNyygxEiIShxcuYTFoheLYkb/14ygfQyC0hLLP/HARLm FFCXOPvnAzOILSqgInFtfzvbBEahWUi6ZyHpnoXQvYCReRWjbEpulW5uYmZOcWqybnFyYl5e apGuhV5uZoleakrpJkZwoLuo7mCccEjpEKMAB6MSD++PpGY/IdbEsuLK3EOMkhxMSqK8m5ta /IT4kvJTKjMSizPii0pzUosPMUpwMCuJ8PoXAOV4UxIrq1KL8mFS0hwsSuK8r3c4+AkJpCeW pGanphakFsFkZTg4lCR4z7cANQoWpaanVqRl5pQgpJk4OEGG8wANfwBSw1tckJhbnJkOkT/F qCglznsFJCEAksgozYPrhSWiV4ziQK8I854DqeIBJjG47ldAg5mABn8tbAQZXJKIkJJqYNQs enJu+rKQxrr41oorbtPKVnJJXOFsvbuw4v/emAs15js/XCubUCi44fdBeZf1d3T7AndIKXA3 fp67KnIiU2jszZ9CSTNnvnGfxpbzdO+5rWcmLU9v7NpiOjHqHoP82WmaiyN+fvHQCSp5Eutp l5T45KCm8+RaXsugW5V7asPs91XpcLBXOiuxFGckGmoxFxUnAgBnF3+2HwMAAA== 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: Thu, 29 Sep 2011 14:49:10 -0000 Quoth Ali Polatel on Sep 28 at 10:53 am: > On Tue, 27 Sep 2011 18:46:22 -0400, Austin Clements wrote: > > Quoth David Bremner on Sep 27 at 1:59 pm: > > > On Tue, 27 Sep 2011 16:25:58 +0300, Ali Polatel 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.