GNU bug report logs - #73838
31.0.50; Problems in note_mouse_highlight if -nw

Previous Next

Package: emacs;

Reported by: Gerd Möllmann <gerd.moellmann <at> gmail.com>

Date: Wed, 16 Oct 2024 10:48:02 UTC

Severity: normal

Found in version 31.0.50

Fixed in version 31.1

Done: Gerd Möllmann <gerd.moellmann <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 73838 <at> debbugs.gnu.org
Subject: bug#73838: 31.0.50; Problems in note_mouse_highlight if -nw
Date: Thu, 17 Oct 2024 14:12:03 +0200
Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Cc: 73838 <at> debbugs.gnu.org
>> Date: Thu, 17 Oct 2024 09:03:13 +0200
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> > If that's not what you are suggesting, I
>> > wonder what is wrong with the current code that we need to make
>> > changes which are basically half-solutions.  If the problem is access
>> > to unrelated memory, that is easy to fix by just adding enough slack
>> > to tty_output definition, for example.
>> 
>> You mean by making sizeof (struct tty_output) == sizeof (ns_output) in
>> my case, and let it go? Bloodcurdlingly horrible! I don't even want to
>> think about it.
>
> Why is it a problem to add some dummy buffer to a struct? what's so
> horrible about that?  The reason is to let ASAN build run without
> false positives.

Well, for me it's not a false positive. ASAN is absolutely right about
it says. We are accessing memory that's not there because we are
accessing something of the wrong type. Making the memory the memory
appear doesn't change the fact that we are still accessing something as
the wrong type. I find that horrible, sorry :-).

But it doesn't matter. I have what I posted in my branch, so it doesn't
prevent me personally from proceeding.

> Alternatively, cannot you tell ASAN in some way that this code is
> okay?

The docs say clang supports an ottribute for that 

  Disabling Instrumentation with __attribute__((no_sanitize("address")))

Haven'tever used that, though, so I don't know if it works.




This bug report was last modified 212 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.