bug#77924: 31.0.50; [Feature branch] Change marker implementation

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>>
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>
>>>> Are there any backward-incompatible changes with this?
>>>
>>> None I'm aware of.
>>>
>>>> Do all the tests still pass as well as they did before these changes?
>>>
>>> I got a SEGV in buffer-tests right now when I checked again that went
>>> away an a second run. So I'll have to check that.
>>
>> SUMMARY OF TEST RESULTS
>> -----------------------
>> Files examined: 530
>> Ran 8041 tests, 7765 results as expected, 0 unexpected, 276 skipped
>> [scratch/text-index] gerd@mini 2025-04-19 22:51
>>
>> Now fixed.
>
> Commit message:

A warning: the branch currently contains a bug that can lead to a stack
overflow that looks like this:

(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
(code=2, address=0x16b0ffff0)
    frame #0: 0x000000010451bc38 
emacs`ensure_charpos_indexed(b=0x0000000107280d28, charpos=4415031360) at 
text-index.c:356
    frame #1: 0x000000010451bb10 
emacs`text_index_charpos_to_bytepos(b=0x0000000107280840, charpos=25980) at 
text-index.c:621:3
    frame #2: 0x00000001046cc1d0 
emacs`marker_vector_bytepos(m=0x0000000107280d28) at marker-vector.c:323:10
    frame #3: 0x0000000104529aec emacs`marker_byte_position(marker=(struct 
Lisp_Marker *) $52 = 0x0000000107280d28) at marker.c:376:29
    frame #4: 0x000000010451cfb4 emacs`BUF_PT_BYTE(buf=0x0000000107280840) at 
buffer.h:909:6
!gud 909:6:/Users/gerd/emacs/github/cl-packages/src/buffer.h
  * frame #5: 0x000000010451bdec 
emacs`narrow_charpos_bounds(b=0x0000000107280840, prev=0x000000016b100178, 
next=0x000000016b100168, charpos=25980) at text-index.c:549:42
    frame #6: 0x000000010451bb78 
emacs`text_index_charpos_to_bytepos(b=0x0000000107280840, charpos=25980) at 
text-index.c:628:23
    frame #7: 0x00000001046cc1d0 
emacs`marker_vector_bytepos(m=0x0000000107280d28) at marker-vector.c:323:10
    frame #8: 0x0000000104529aec emacs`marker_byte_position(marker=(struct 
Lisp_Marker *) $52 = 0x0000000107280d28) at marker.c:376:29
    frame #9: 0x000000010451cfb4 emacs`BUF_PT_BYTE(buf=0x0000000107280840) at 
buffer.h:909:6
    frame #10: 0x000000010451bdec 
emacs`narrow_charpos_bounds(b=0x0000000107280840, prev=0x000000016b1002c8, 
next=0x000000016b1002b8, charpos=25980) at text-index.c:549:42
    frame #11: 0x000000010451bb78 
emacs`text_index_charpos_to_bytepos(b=0x0000000107280840, charpos=25980) at 
text-index.c:628:23
    frame #12: 0x00000001046cc1d0 
emacs`marker_vector_bytepos(m=0x0000000107280d28) at marker-vector.c:323:10
    frame #13: 0x0000000104529aec emacs`marker_byte_position(marker=(struct 
Lisp_Marker *) $52 = 0x0000000107280d28) at marker.c:376:29
    frame #14: 0x000000010451cfb4 emacs`BUF_PT_BYTE(buf=0x0000000107280840) at 
buffer.h:909:6

The reason for that is that functions like BUF_PT (and maybe others) are
"too smart", in the case of indirect buffers, for what I need in the
text index. I'll fix that a bit later today.