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 DC6D2431FD0 for ; Thu, 22 Dec 2011 11:02:07 -0800 (PST) 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 b9SAn5KmYL7i for ; Thu, 22 Dec 2011 11:02:06 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU [18.9.25.15]) by olra.theworths.org (Postfix) with ESMTP id D9024431FB6 for ; Thu, 22 Dec 2011 11:02:05 -0800 (PST) X-AuditID: 1209190f-b7f8a6d000000914-77-4ef37eabe63b Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 66.59.02324.BAE73FE4; Thu, 22 Dec 2011 14:02:03 -0500 (EST) 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 pBMJ22Ef019051; Thu, 22 Dec 2011 14:02:03 -0500 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 pBMJ21NA019341 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 22 Dec 2011 14:02:02 -0500 (EST) Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.77) (envelope-from ) id 1Rdnuz-00006O-9N; Thu, 22 Dec 2011 14:03:05 -0500 Date: Thu, 22 Dec 2011 14:03:05 -0500 From: Austin Clements To: David Edmondson Subject: Re: [RFC][PATCH] notmuch: Workaround to allow ignoring non-void function return. Message-ID: <20111222190305.GA324@mit.edu> References: <1324503532-5799-1-git-send-email-dme@dme.org> <20111222070345.GI10376@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42IRYrdT111d99nP4NgKMYt9d7YwWVy/OZPZ gclj1/O/TB7PVt1iDmCK4rJJSc3JLEst0rdL4Mp4/rmFveAfV0Vr2wbGBsZvHF2MnBwSAiYS R/qfMEPYYhIX7q1n62Lk4hAS2Mco8WDWbShnA6PEgU9HoJyTTBKLH/UwQzhLGCV+LN/N1MXI wcEioCqx+G8EyCg2AQ2JbfuXM4LYIgKKEv+/rWAHsZkFpCW+/W5mArGFBaIlrv44zgJi8wpo Sdx4uIgRYmY/o0THwzVsEAlBiZMzn7BANAMV/XsJtgtk0PJ/YC9wCthIvD58khXEFhVQkZhy chvbBEahWUi6ZyHpnoXQvYCReRWjbEpulW5uYmZOcWqybnFyYl5eapGuiV5uZoleakrpJkZQ YHNK8u9g/HZQ6RCjAAejEg9vZdFnPyHWxLLiytxDjJIcTEqivE+rgUJ8SfkplRmJxRnxRaU5 qcWHGCU4mJVEeCsYgXK8KYmVValF+TApaQ4WJXFeNa13fkIC6YklqdmpqQWpRTBZGQ4OJQne q7VAjYJFqempFWmZOSUIaSYOTpDhPEDDj4HU8BYXJOYWZ6ZD5E8xKkqJ864ASQiAJDJK8+B6 YYnnFaM40CvCvFtBqniASQuu+xXQYCagwducP4AMLklESEk1MJppGntcPxUwKzqxetESlp1p 272m2Hg4ZAm/tEk5kZpuFGakamgTZHPEvOu2xjKpH34MM/f8/rKf5XjzZB6fps1TN/lw2nYu 6VOIUgyewHlr29t/15hP7jHb/W2/Zvbnz7HH/+1ewJS10rcqzt2gOJS78RbnhGv2SRyWFcpt snpHr/HLldp+UGIpzkg01GIuKk4EAMK2GysXAwAA 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, 22 Dec 2011 19:02:08 -0000 Quoth David Edmondson on Dec 22 at 7:21 am: > On Thu, 22 Dec 2011 02:03:45 -0500, Austin Clements wrote: > > I must admit I haven't been following the warnings problem very > > closely, but perhaps we shouldn't be ignoring these return codes? > > In general I agree, but what would we do if writing an error message to > stderr fails? This was discussed on IRC, but calls to write(2) should never be bare. I believe it's marked warn_unused_result not because libc is so concerned with people checking for error returns (otherwise all sorts of things would be marked warn_unused_result) but because even a successful write can be a short write. Hence, not checking the result is a bug, even if you don't care about errors. fwrite's a little trickier, since it will only short-write on an error, so to me it seems perfectly legitimate to ignore the result if you don't care about errors. I don't seem to have whatever glibc version the buildbot does that marks these warn_unused_result, but I can reproduce it by adding __attribute__((warn_unused_result)) ssize_t write(int fd, const void *buf, size_t count); __attribute__((warn_unused_result)) size_t fwrite(const void *ptr, size_t size, size_t nmemb, FILE *stream); to notmuch-client.h. Testing with these, if I add any form of result checking, even if it does nothing in most cases, GCC is quiet.