bug#14062: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 15 Apr 2013 21:22:00 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: drew.adams@oracle.com, lekktu@gmail.com, 14062@debbugs.gnu.org
> 
>  > But for nil, BUFFERP will return zero, and the code that uses XBUFFER
>  > should not be called, IMO.
> [...]
>  > But the uninitialized contents field should be zero, no?  Again, it
>  > should not pass the BUFFERP test.
>  >
>  > So the mystery still stands.
> 
> You mean that the w->contents argument of XBUFFER _always_ passes the
> BUFFERP test first and then fails at the assertion in XBUFFER?

Yes, see the definition of the WINDOW_WANTS_HEADER_LINE_P macro, where
we have:

     && BUFFERP (W->contents)					\
     && !NILP (BVAR (XBUFFER (W->contents), header_line_format))	\

Should a condition be always evaluated left to right?  Or is a
processor allowed to issue these two parts in parallel, if it has more
than one processing unit available?

> How can that make sense?

Exactly my question.  But the evidence is unequivocal: the assertion
in XBUFFER is the one that aborts.  I disassembled the code to make
sure I got that correctly.  This was an unoptimized build, so any
tricks with folding several different calls into one don't happen.