emacs-devel
[Top][All Lists]
Advanced

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

Re: san_ignore_object not found at link time


From: Philipp Stephani
Subject: Re: san_ignore_object not found at link time
Date: Sat, 1 Aug 2020 21:21:01 +0200

Am Sa., 1. Aug. 2020 um 21:17 Uhr schrieb Philipp Stephani
<p.stephani2@gmail.com>:
>
> Am Sa., 1. Aug. 2020 um 20:35 Uhr schrieb Philipp Stephani
> <p.stephani2@gmail.com>:
> >
> > Am Sa., 1. Aug. 2020 um 20:32 Uhr schrieb Eli Zaretskii <eliz@gnu.org>:
> > >
> > > > From: Philipp Stephani <p.stephani2@gmail.com>
> > > > Date: Sat, 1 Aug 2020 20:29:29 +0200
> > > > Cc: Alan Third <alan@idiocy.org>, raman <raman@google.com>,
> > > >       Emacs developers <emacs-devel@gnu.org>
> > > >
> > > > >   alloc.c: In function 'mark_maybe_object':
> > > > >   alloc.c:4641:14: warning: cast to pointer from integer of different 
> > > > > size [-Wint-to-pointer-cast]
> > > > >    4641 |   void *po = (char *) ((intptr_t) (char *) XLP (obj)
> > > > >         |              ^
> > > > >
> > > > > This is a 32-bit build --with-wide-int, in case it matters, where
> > > > > EMACS_INT is a 64-bit data type.
> > > >
> > > > This is due to the unrelated commit a2323c7ccb. (I just happened to
> > > > push both commits at the same time.)
> > > > It looks like LISP_WORD_TAG in a wide int build is a 64-bit number, so
> > > > that the entire expression gets widened to a 64-bit number. However,
> > > > since it's cast back to a pointer, the value has to fit in 32 bits.
> > >
> > > The pointer is there, you just cannot safely extract it by casting to
> > > a narrower data type.  You need to explicitly mask the MSBs by
> > > shifting or some other bit fiddling.
> >
> > IIUC casting between unsigned integer types is guaranteed to have the
> > same effect.
>
> I've now used INT_SUBTRACT_WRAPV, which should guarantee that the
> offset is defined and fits within an intptr_t.

However, I guess when using wide ints *and* MSB tags the subtraction
might overflow, so maybe the assertion should be conditioned on that
case.



reply via email to

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