From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lennart Borgman Newsgroups: gmane.emacs.devel Subject: Re: System calls without error checks in w32 Date: Sun, 30 May 2010 20:02:42 +0200 Message-ID: References: <83ocfytxhg.fsf@gnu.org> <83mxvitsay.fsf@gnu.org> <83ljb2tn6i.fsf@gnu.org> <83k4qmt7lb.fsf@gnu.org> <83hblpthpt.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1275242593 6152 80.91.229.12 (30 May 2010 18:03:13 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 30 May 2010 18:03:13 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun May 30 20:03:12 2010 connect(): No such file or directory Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OImqt-0003Vh-5Z for ged-emacs-devel@m.gmane.org; Sun, 30 May 2010 20:03:11 +0200 Original-Received: from localhost ([127.0.0.1]:44124 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OImqr-0001cY-C4 for ged-emacs-devel@m.gmane.org; Sun, 30 May 2010 14:03:09 -0400 Original-Received: from [140.186.70.92] (port=39598 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OImqm-0001cR-Jo for emacs-devel@gnu.org; Sun, 30 May 2010 14:03:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OImql-00035c-5q for emacs-devel@gnu.org; Sun, 30 May 2010 14:03:04 -0400 Original-Received: from mail-gw0-f41.google.com ([74.125.83.41]:46155) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OImql-00035V-3a; Sun, 30 May 2010 14:03:03 -0400 Original-Received: by gwb19 with SMTP id 19so2809668gwb.0 for ; Sun, 30 May 2010 11:03:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=y3vW0sPK7sfPI9z8l2qJfkcIBQEbdywsct6TyP+uQJo=; b=S8s5KIqvT1uuGQzzmKXPqe9OoERUqqG6uDHC8f2PsdQ1WZzMvAo7tCBceL9Ycqcqhv CQQDcgHPpsIyaQa4QkuSea0D4KdTnVJJWuML181d4MhZhNOAp+F5rqNyp25I3fjwLcwQ FJocfzl/5GgvfHhT7k3f5MdpyxUf6e8NFP4os= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=TBx7ihKsuq4zvcZ7Fnalzh6d/HepTA4KrhwRc0X6NUKUY1xApqa+yticdxwso7/QJB SL1gDKL9vXjItyZw1b+bEYf6kw5oKCI+WzassktOGtjbQiPh4yQY38DD1t5Z9Oncli5Y PY4JyU+4GTv1vu0+qRbD73WnCz5a4euZLbDOw= Original-Received: by 10.101.28.39 with SMTP id f39mr3644360anj.69.1275242582153; Sun, 30 May 2010 11:03:02 -0700 (PDT) Original-Received: by 10.100.44.20 with HTTP; Sun, 30 May 2010 11:02:42 -0700 (PDT) In-Reply-To: <83hblpthpt.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:125365 Archived-At: On Sun, May 30, 2010 at 7:36 PM, Eli Zaretskii wrote: >> >> On Sun, May 30, 2010 at 5:02 AM, Eli Zaretskii wrote: >> > >> > In any case, the solution you suggest is not a good one, because it >> > obfuscates the source code and makes it harder to read and understand. >> >> >> Are you saying that checking the return values of system calls should >> be avoided because it makes the code to difficult to read? > > No. Fine. >> Remember that what I suggest is basically >> >> =C2=A0 =C2=A0if (bad_return_value) DebPrint (("error this_function.ApiFu= nction >> =3D> %d", bad_return_value)); > > What purpose does this serve? =C2=A0This isn't "checking return values fo= r > errors", because this has no effect for the majority of users who > don't run Emacs under a debugger. The debugger of course does not have an effect on those users. But what do you want to say? My intention is to get a chance to know why a system call failed. That is a way to find those errors that are a bit harder to find than those you may see directly by inspecting the code. > Their Emacs will still crash if it > hits bad_return_value. =C2=A0I thought you were arguing for making the > Emacs code more robust in the face of possible failures of the APIs it > calls. Yes, of course, that should be done at the same time. > If you want more debugging aids, I don't object, but then I have no > interest in such additions, either. =C2=A0Typically, such additions are > only good as long as you debug some specific problem, so keeping them > in the code after that is waste of bytes. It seems like you think that problems with system calls are just like any other problem in the code. For problem in Emacs code itself your strategy here is of course good. System calls, however is like a black box. You have to follow the rules for calling the black box, but do not know exactly what is inside, you can only watch the outcome to learn more. One example of this is when I see Emacs going totally weird. That happens quite often and I am not sure what is happening. It might in my cases be problems with edebug or it might be problems with the system calls that makes the depends on resource exhaustion in the black system box. To be able to fix it I need some kind of logging of the system calls. So I really prefer that those debug calls for check system calls are there permanently. >> =C2=A0 =C2=A0W32DEBPRINT (this_function, ApiFunction, bad_return_value, = 0); > > This is even worse, because it's impossible to understand what this > does without looking up the magical W32DEBPRINT macro. I think it has some advantages, actually. It is easy to see and distinguish from the normal code. It can be a null op in non-debugging compilations. And it is very easy to understand immediately once you have looked up the magical W32DEBPRINT - which is quite easy to do with Emacs tools. But maybe you meant something else?