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: Lennart Borgman
Subject: Re: System calls without error checks in w32
Date: Sun, 30 May 2010 20:02:42 +0200

On Sun, May 30, 2010 at 7:36 PM, Eli Zaretskii <address@hidden> wrote:
>>
>> On Sun, May 30, 2010 at 5:02 AM, Eli Zaretskii <address@hidden> 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 via email to

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