bug#46915: [PATCH] Remove unecessary change_req arg from overlays_at()

[Matt Armstrong]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Matt Armstrong <matt@rfc20.org>
>> Date: Wed, 03 Mar 2021 18:29:28 -0800
>> 
>> I was scratching my head trying to figure out why overlays_at() had such
>> a complex function signature.  It turns out that it does not need to be
>> so complex now and, I think, it never did.
>> 
>> >From 0337e4823b32dd15bdae1f61df12b5f68170e360 Mon Sep 17 00:00:00 2001
>> From: Matt Armstrong <matt@mdeb>
>> Date: Wed, 3 Mar 2021 16:31:02 -0800
>> Subject: [PATCH] Remove unecessary change_req arg from overlays_at()
>> 
>> The change_req arg was an unecessary complexity.  It only changed what
>> might be assigned to the *prev_ptr arg, and all callers that passed a
>> non-null prev_ptr also passed a true change_req.
>> 
>> This makes it clear that no caller desires the behavior that would
>> have occurred with a non-null prev_ptr and a false change_req.
>> 
>> For archaeologists, the above invariants appear to have been true from
>> the beginning, and whatever bug fixed by the commits below need not
>> have been controlled with a new boolean arg.  See commits
>> ac869cf715 ((overlays_at): Add CHANGE_REQ parameter, 2000-08-08) and
>> 1d5f4c1de4 ((overlays_at): Only let CHANGE_REQ inhibit an assignment
>> of startpos to prev when startpos == pos, 2000-10-25).
>
> Could you please tell what are the benefits of this change?  The
> signature may be complex, but it doesn't currently cause any problems,
> does it?  I'd prefer not to change code that is working and causes no
> trouble.

I do agree that changing code should serve some purpose.

I have been looking at the performance problems related to overlays,
mentioned in etc/TODO.  I know that this has been worked on by multiple
people over the years, but never successfully completed.  I have seen
the features/noverlay branch but have not yet convinced myself that the
code there is the right thing.  You could say that I am basically doing
a thorough code review of that approach.  I have contacted all the
people who have formerly worked on this and all of them have no plans to
resume their work, so there is space for me to do this.

The first thing I do on a project like this is determine the
functionality the current thing is providing to the rest of the system.
In other words, what is its "real" API, and how does that API differ
from its "advertised" API?

So, the benefit of this change can be summarized:

 - We don't think the current overlay implementation is necessarily the
   right thing, so we can presume that this area will change at some
   point.

 - If we simplify the API, future changes will be easier to review.  In
   particular, nobody will ever have to think about callers that want a
   *PREV_PTR value with a false CHANGE_REQ, and no future implementer
   will feel like they need to provide that functionality.