emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: System calls without error checks in w32


From: Juanma Barranquero
Subject: Re: System calls without error checks in w32
Date: Sun, 30 May 2010 21:24:33 +0200

On Sun, May 30, 2010 at 20:02, Lennart Borgman
<address@hidden> wrote:

> 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.

If you have DebPrint for every system call, and some of them return
trivial errors, debugging will sometimes be harder just because of the
noise.

> 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.

I think you'll see that many system calls won't ever return an error
(because the error conditions are pretty infrequent). Some of them
will, for example system calls related to file manipulation (because
of nonexistent or nonaccesible files, etc.); it would be interesting
to know how many of those don't have already checking in place.

> 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.

Does that happen to you with your patched Emacs, or unpatched? Because
I see occasional crashes, but not nearly as frequently as it seems to
happen to you (not by a loooong shot), and I have not seem "weird"
behavior (unresponsive Emacs, looping, etc.) perhaps for years.

> To be able to fix it I need some kind of logging of
> the system calls.

Because you somehow assume that the trouble is likely related to bad
system calls; most Emacs bugs aren't.

>> 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.

IMHO is horribly ugly. If you're going to have error checks, better to
have them on the clear.

    Juanma



reply via email to

[Prev in Thread] Current Thread [Next in Thread]