Comparing symbol-with-position using eq (was: Help please! To track down GC trying to free an already freed object.)

[Alex <agrambot@gmail.com>]

Hello, Alan.

Alan Mackenzie <acm@muc.de> writes:

> On Thu, Apr 04, 2019 at 22:49:22 -0600, Alex wrote:
>
>> I apologize if this topic already reached its conclusion, but IMO
>> having eq return true for two different object types is quite
>> surprising behaviour.
>
> We are comparing two symbols, both of which are 'foo, but one of which is
> annotated with its position in a source file.  The two symbols are the
> same symbol.

Is it not comparing a symbol with a pseudovector containing that symbol
and a position?

> I understand the reaction to the idea, though.  Even though the
> representation of these two objects is different, conceptually they are
> the same object.

Similar objects, but I don't believe that's enough for eq. Consider that
it's regarded non-portable in Lisp to compare integers with eq since the
same number may be represented by different objects, or (eq 3 3.0), or
(eq (list 1 2) (list 1 2)).

> But consider: on a make bootstrap I did last night, there were 332
> warning messages from the byte compiler.  Of these, only 80 gave the
> correct line/column position, the other 252 being wrong.  There have been
> several bug reports from users complaining about such false positions.
> This is what I'm trying to fix.

I agree that it's a problem very much worth fixing; thank you for
working on it.

>> Is it out of the question to leave eq alone and introduce, e.g.,
>> eq-excluding-position that strips possible positions before comparison?
>
> It is, rather.  To implement this would involve rewriting everything
> which calls eq and is used by the byte compiler, to call
> eq-excluding-position instead.  These functions would need to exist in
> two versions.  There are rather a lot of functions which use eq.  ;-)

Why would you need to rewrite the helper procedures that the byte
compiler uses? What about stripping the position at each relevant call
site?