From: Lennart Borgman <lennart.borgman@gmail.com>
To: Juanma Barranquero <lekktu@gmail.com>
Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
Subject: Re: System calls without error checks in w32
Date: Mon, 31 May 2010 04:36:15 +0200 [thread overview]
Message-ID: <AANLkTilVW3vPL55bob8oNf6Fwtjn4UdRl-cDD0GU8o2G@mail.gmail.com> (raw)
In-Reply-To: <AANLkTikU8rrGgne3snlDlW68exZwrbFkkDGNS8CALR_D@mail.gmail.com>
On Mon, May 31, 2010 at 4:02 AM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Mon, May 31, 2010 at 02:58, Lennart Borgman
> <lennart.borgman@gmail.com> 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...
Exactly. That is why debug output might be helpful.
>> 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.
Yes, but isn't it a really good reason to always check the return code
from system calls?
> I see no practical difference between my take of the situation
> (regarding your patches) and yours.
Maybe it is just me then. But I have thrown away a good deal of them
just to get less work (even if some of them were bug fixes).
>> 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?
Because they are not related to that part of the code.
>> No ;-)
>
> Hmm... allow me to disagree ;-)
What can I do? ;-)
> 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.
Yes, of course. But keeping a commented out one line debug output call
might be quit useful in some places.
>> 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.
Yes, I know.
next prev parent reply other threads:[~2010-05-31 2:36 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-29 2:38 System calls without error checks in w32 Lennart Borgman
2010-05-29 17:43 ` Eli Zaretskii
2010-05-29 18:42 ` Lennart Borgman
2010-05-29 19:35 ` Eli Zaretskii
2010-05-29 20:02 ` Lennart Borgman
2010-05-29 21:25 ` Eli Zaretskii
2010-05-29 21:30 ` Lennart Borgman
2010-05-30 3:02 ` Eli Zaretskii
2010-05-30 3:26 ` Lennart Borgman
2010-05-30 17:36 ` Eli Zaretskii
2010-05-30 18:02 ` Lennart Borgman
2010-05-30 19:24 ` Juanma Barranquero
2010-05-30 22:37 ` Lennart Borgman
2010-05-30 23:03 ` Juanma Barranquero
2010-05-30 23:28 ` Lennart Borgman
2010-05-31 0:10 ` Juanma Barranquero
2010-05-31 0:58 ` Lennart Borgman
2010-05-31 2:02 ` Juanma Barranquero
2010-05-31 2:36 ` Lennart Borgman [this message]
2010-05-31 3:06 ` Juanma Barranquero
2010-05-31 3:05 ` Eli Zaretskii
-- strict thread matches above, loose matches on Subject: below --
2010-05-31 9:18 grischka
2010-06-05 17:15 ` Jason Rumney
2010-06-07 10:37 ` grischka
2010-06-07 14:54 ` Stephen J. Turnbull
2010-06-07 15:23 ` Lennart Borgman
2010-06-07 17:21 ` grischka
2010-06-07 17:30 ` Lennart Borgman
2010-06-07 18:54 ` grischka
2010-06-08 0:32 ` Lennart Borgman
2010-06-08 0:34 ` Lennart Borgman
2010-06-07 19:56 ` Stefan Monnier
2010-06-07 23:35 ` Lennart Borgman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AANLkTilVW3vPL55bob8oNf6Fwtjn4UdRl-cDD0GU8o2G@mail.gmail.com \
--to=lennart.borgman@gmail.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=lekktu@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).