bug#33498: 26.1; Unable to delete minibuffer-only+child frames

[martin rudalics]

> Unfortunately the fix broke builds configured with
> --enable-gcc-warnings, as GCC complains about the use of an
> uninitialized variable that appears to be a typo in the fix. I installed
> the attached patch to unbreak the build; please check it to make sure
> that I understood the intent of the fix correctly.

Many thanks for catching this, your fix is correct.  Unfortunately,
it's impossible for me to trigger a crash in a running Emacs since
frame1 apparently gets assigned the "correct" value in one of the
loops executed before.  Using these initial settings

(setq initial-frame-alist '((minibuffer . child-frame)))
(setq default-frame-alist '((minibuffer)))

and subsequently evaluating

;; Assign initial and minibuffer frame.
(setq initial-frame (selected-frame))
(setq minibuffer-frame (window-frame (minibuffer-window)))
;; Make a new frame whose minibuffer window should be on
;; minibuffer-frame.
(make-frame)
;; Make minibuffer frame invisible.
(make-frame-invisible minibuffer-frame)
;; Delete initial frame.
(delete-frame initial-frame)

the last one could trigger a crash but minibuffer-frame just becomes
visible as expected because frame1 _is_ minibuffer_child_frame there.

> It's a good idea to use './configure --enable-gcc-warnings' when making
> changes to the C code in Emacs, as GCC is reasonably good at catching
> typos like this, and typically does not generate too many false alarms.

I build with

Configured using:
 'configure --prefix=/c/emacs-git/trunk/dbg --with-gnutls=no
 --without-pop --enable-checking=yes --enable-gcc-warnings=warn-only
 --enable-check-lisp-object-type=warn-only 'CFLAGS=-O0 -g3
 -Wno-logical-op''

ever since but it seems that gcc 4.8.1 is simply too old to catch such
subtle bugs (just verified by building with the buggy version again).

Thanks again for the fix, martin