Re: System calls without error checks in w32

[Juanma Barranquero]

On Mon, May 31, 2010 at 02:58, Lennart Borgman
<address@hidden> 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