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

[Lennart Borgman]

On Mon, Jul 4, 2011 at 03:21, Juanma Barranquero <lekktu@gmail.com> wrote:
>
>> 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.

A debug message could still help.

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

If that is taken care of I agree of course.

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

A bad assumption in my book.

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

Yes, it is extra complexity. But I think the extra complexity that is
the result of not doing this error checking is much, much worse. There
might be very serious troubles and you have no idea what it is.

Note that not only errors in Emacs code can cause problems here, but
compiler bugs etc.

>> That one in x_free_frame_resources (that I told about 2010-06-13).
>
> Again: what change? Adding error checking?

Just switching the order:

  The problem seems to be in x_free_frame_resources. Should not
  free_frame_menubar be called before my_destroy_window there?

Hm. I am not quite sure now. Something in my memory is waving a flag
and saying something about it. Can't see it now ;-)

Could you please check the MS doc and see if these calls should be
switched? When I read them I came to that conclusion, but it might be
wrong (and the MS doc might also be wrong).

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

I did not notice now. Sorry.