bug#6414: f->output_data.w32->menubar_widget uninitialized?

[Juanma Barranquero]

On Mon, Jul 4, 2011 at 03:08, Lennart Borgman <lennart.borgman@gmail.com> wrote:

> This call was related to the menus.

This bug report was supposedly about menus, but was in fact about
system calls returning errors, and no menu bug in sight...

> I believe many of the heavy menu users might be using my patched
> version (since this allows them to use the windows-key as META). That
> might be the reason you do not see the bug reports.

Perhaps. It is hard to say.

> Of course, but you just do not know it was a race condition. You have
> no clue at all, since such a condition with a system call can give
> very strange results. (I have seen such cases.)

It's irrelevant whether the user knows that it was a race condition.
Either s/he sees a bug, or s/hee does not.

> I would say every system call. Why do you think some of them should be
> excluded from error checking?

There are many reasons. In some cases, an error means something could
not be done, but reporting it does not help and the fact that it was
not done does not cause any harm. In other cases, a system call can
return an error, but it just never happens (or if it happens, the
reason is serious enough that Emacs failing will not be the biggest
problem).

Adding error checking to all system calls adds unneeded complexity in
these cases where there's nothing to do if the system call fails, and
it failing is not going to cause data loss or the World War III.

> That one in x_free_frame_resources (that I told about 2010-06-13).

Again: what change? Adding error checking?

> I wonder why I cared to add that check then. Perhaps was it executed
> before, I have no idea now.

Then, why did you comment it?

    Juanma