From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: Re: System calls without error checks in w32 Date: Mon, 31 May 2010 04:02:55 +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 X-Trace: dough.gmane.org 1275271643 16417 80.91.229.12 (31 May 2010 02:07:23 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 31 May 2010 02:07:23 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Lennart Borgman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 31 04:07:21 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 1OIuPP-0006AK-QV for ged-emacs-devel@m.gmane.org; Mon, 31 May 2010 04:07:20 +0200 Original-Received: from localhost ([127.0.0.1]:38038 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OIuLd-0001Bj-EL for ged-emacs-devel@m.gmane.org; Sun, 30 May 2010 22:03:25 -0400 Original-Received: from [140.186.70.92] (port=60551 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OIuLV-00019E-Vc for emacs-devel@gnu.org; Sun, 30 May 2010 22:03:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OIuLU-0002jd-Mx for emacs-devel@gnu.org; Sun, 30 May 2010 22:03:17 -0400 Original-Received: from mail-fx0-f41.google.com ([209.85.161.41]:42020) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OIuLU-0002jT-CW; Sun, 30 May 2010 22:03:16 -0400 Original-Received: by fxm11 with SMTP id 11so2607312fxm.0 for ; Sun, 30 May 2010 19:03:15 -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; bh=CPjoF151eU7NgdLj8E2v96aLIim/F+uoriltF3LOLfc=; b=EbVZK2g3w3HCuRtq0FWe53XuSDgXUEK1DY8ltjyx11Ihj9kBtIkwra/UNJRgiQvRY+ syHF6ORS67E0Ie7ZGjLKj5gsItyGlXZNMZ8oMFlBbBs2PIhW42Z60dKCznBeACE0fcw2 zo9PgnXYaD3FVY7gH0SemqWaGgcPCmzLJ3f+k= 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; b=SDcUdFPA4Yg3V0h27gMOcTexitb0VDz2Sz4JVRpKN64x44JXIuTnvFJDSnl+EQmP8x PBNgGoT3BntkzlmSg0mGlZ+DJlEnjbYIfSVg5Ew4KJ1V8F0ufNfrV+9dfeTO/9CqORFQ bjTnjkEHUYEL8mBJxJz22HHCUCzlFpANWEw1I= Original-Received: by 10.102.16.24 with SMTP id 24mr1478184mup.121.1275271395136; Sun, 30 May 2010 19:03:15 -0700 (PDT) Original-Received: by 10.204.32.18 with HTTP; Sun, 30 May 2010 19:02:55 -0700 (PDT) In-Reply-To: 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:125384 Archived-At: On Mon, May 31, 2010 at 02:58, Lennart Borgman wrote: > I don't think so. It is just much more difficult to track some of > these. For example I know Drew recently wrote about problems when > creating new frames. It is quite hard to both understand what is > happening and what is a bug and what is not. Well, I'd say that should be the first step... > I just mean that the normal C code (i.e. not related to system calls) > seems better checked on w32. Not sure what do you mean with "better checked". Obviously it is easier to know what one of our own C functions is doing that what a Windows system call does, so it's less likely that a return code from a C function is ignored. > Maybe you are missing my point. The system tries to stay stable. There > are timing issues etc. Maybe. Sometimes it seems like you assume your interlocutor knows it all about the bugs you encounter; I tend to find your descriptions vague and hard to follow (not necessarily your fault, of course). > When I entered this list I went into a long discussion about the > problems with printing on the w32 side. I actually felt I wasted a lot > of time when I told that the code was in error. Since then I have > thought it is less waste of time to keep the patches in my patched > version. Now and then I ask if things have changed. If they have not I > just skip it, but with some regret about the extra trouble and lost > work. I see no practical difference between my take of the situation (regarding your patches) and yours. > I have done that many times (or sent reports to the list before) but > these kind of errors are not easy to track down. And since I have some > patches (that correct some bugs, but also makes other bugs more > visible) they tend to be dismissed. I don't think so. They aren't dismissed because of your patches, but because they are (at least, some that I've followed) very hard to reproduce in standard Emacs. > It seems much more trouble reporting the problems than fixing them. > Maybe I should try to make a "system calls fix branch" from savannah > and pick them one by one when I have time. Perhaps it'd be a good idea. > I have an example where I create a frame contact a web page in > pause.el. Is that specific enough? (You have to run my patched code to > see it since I can't do the frame manipulation I need without that.) Then, why are you sure the problem isn't in your code? Surely if it is a bug in Emacs there will be a way to show it with the trunk code? > No ;-) Hmm... allow me to disagree ;-) > I don't think so. You should most often not crash Emacs because of bad > system call return status. You should take a relevant action. That's explicit in my comment. If you can take relevant action, do it (not DebPrint, but a really relevant action). If you cannot, and the bug is real, then abort. > Of course, but you may be interested in information about what happened too. While debugging. Not as a general principle. I don't want to run Emacs under GDB for a totally unrelated reason and have a lot of noise. I want that "noise", if it is relevant, to be acted upon. So, instead of just adding lots of DebPrints, it would be more sensible to add them locally for debugging, find what's happening (surely if you have so many troubles, the error output will be abundant) and either fix it or file a bug report for it. > And the changes that allows better menu handling are also a bit > scaring when merging. They are still only in my code. Perhaps the latter is consequence of the former. Juanma