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 378ED431FD0 for ; Tue, 27 Sep 2011 15:44:04 -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 zbLoGS8DCh85 for ; Tue, 27 Sep 2011 15:44:03 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (DMZ-MAILSEC-SCANNER-5.MIT.EDU [18.7.68.34]) by olra.theworths.org (Postfix) with ESMTP id 99249431FB6 for ; Tue, 27 Sep 2011 15:44:03 -0700 (PDT) X-AuditID: 12074422-b7ff56d00000092f-d6-4e8251b150c5 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 1A.A1.02351.1B1528E4; Tue, 27 Sep 2011 18:44:01 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id p8RMi0dj024998; Tue, 27 Sep 2011 18:44:00 -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 p8RMhwRw014030 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 27 Sep 2011 18:43:59 -0400 (EDT) Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.72) (envelope-from ) id 1R8gPu-0004hP-64; Tue, 27 Sep 2011 18:46:22 -0400 Date: Tue, 27 Sep 2011 18:46:22 -0400 From: Austin Clements To: Ali Polatel , David Bremner Subject: Re: Concerns regarding some library functions Message-ID: <20110927224622.GR17905@mit.edu> References: <871uv2unfd.fsf@gmail.com> <87fwjhx6p5.fsf@convex-new.cs.unb.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87fwjhx6p5.fsf@convex-new.cs.unb.ca> User-Agent: Mutt/1.5.20 (2009-06-14) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmleLIzCtJLcpLzFFi42IRYrdT0d0Y2ORncOIUm8WN1m5Gi+s3ZzJb 9O35xurA7LFz1l12j2erbjF7bDn0njmAOYrLJiU1J7MstUjfLoErY+G9K6wFGzgqLn/oZWlg fMbWxcjBISFgIjFpfXUXIyeQKSZx4d56oDAXh5DAPkaJu5v3sUA4GxglLqy9yQzhnGSSuHx/ FSuEs4RRouPhA0aQfhYBVYlj7z+A2WwCGhLb9i8Hs0UE3CTu/njKDmIzC0hLfPvdzASyWljA TOLVQjmQMK+AjsSbZX1sILaQgJ/EyTOz2CHighInZz5hgWjVkrjx7yVYK8iY5f84QExOASOJ dU1hIBWiAioS1/a3s01gFJqFpHkWkuZZCM0LGJlXMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Zrq 5WaW6KWmlG5iBIe5i9IOxp8HlQ4xCnAwKvHwCjI2+QmxJpYVV+YeYpTkYFIS5RUPAArxJeWn VGYkFmfEF5XmpBYfYpTgYFYS4V1rBpTjTUmsrEotyodJSXOwKInzcu108BMSSE8sSc1OTS1I LYLJynBwKEnw9oEMFSxKTU+tSMvMKUFIM3FwggznARreDFLDW1yQmFucmQ6RP8WoKCXOmwaS EABJZJTmwfXC0tArRnGgV4R5m0CqeIApDK77FdBgJqDBXwsbQQaXJCKkpBoYuULj3l40t/h4 OL70q9k39glHJt0Ty+Of0Ou28NMhC/NLr3vD5Cd/OzHrVtfVxX7ul6V/P1756drc4LnzFfu4 d63eJnHV/mt6J+v0dnlbsY4IMWY/rafOludX5TaH762Tsjyc8UT6YVuXwlRejX0P2nYWfeG9 kFtfvOt7lUnbx9kdolVy8z2fKLEUZyQaajEXFScCAPCErBkeAwAA 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: Tue, 27 Sep 2011 22:44:04 -0000 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. 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.