unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Lennart Borgman <lennart.borgman@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: System calls without error checks in w32
Date: Sun, 30 May 2010 20:02:42 +0200	[thread overview]
Message-ID: <AANLkTil-T_URLzHSRdGozw37igbEFXiq-3PYSvrKNwrE@mail.gmail.com> (raw)
In-Reply-To: <83hblpthpt.fsf@gnu.org>

On Sun, May 30, 2010 at 7:36 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>>
>> On Sun, May 30, 2010 at 5:02 AM, Eli Zaretskii <eliz@gnu.org> 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
>>
>>    if (bad_return_value) DebPrint (("error this_function.ApiFunction
>> => %d", bad_return_value));
>
> What purpose does this serve?  This isn't "checking return values for
> 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.  I 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.  Typically, 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.


>>    W32DEBPRINT (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?



  reply	other threads:[~2010-05-30 18:02 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 [this message]
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
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=AANLkTil-T_URLzHSRdGozw37igbEFXiq-3PYSvrKNwrE@mail.gmail.com \
    --to=lennart.borgman@gmail.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /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).