bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#14062: 24.3.50; emacs_backtrace.txt


From: Eli Zaretskii
Subject: bug#14062: 24.3.50; emacs_backtrace.txt
Date: Tue, 16 Apr 2013 09:08:06 +0300

> Date: Mon, 15 Apr 2013 21:22:00 +0200
> From: martin rudalics <address@hidden>
> CC: address@hidden, address@hidden, address@hidden
> 
>  > 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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]