emacs-devel
[Top][All Lists]
Advanced

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

Re: Building the igc branch on MS-Windows


From: Gerd Möllmann
Subject: Re: Building the igc branch on MS-Windows
Date: Sat, 27 Apr 2024 14:09:26 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

Eli Zaretskii <eliz@gnu.org> writes:

>> I'm creating the MPS pools with support for interior pointers, i.e. a
>> pointer to somehwere inside of an object keeps the object alive. It's
>> not necessary that there exists a pointer to the object start.
>> 
>> Is that's what happening here?

I think I can answer my question above now. It's not like the buffer
text case. AFAICS, face->font is just a plain struct font pointer that
is obtained from XFONT_OBJECT. It's like any other reference from a Lisp
object to another, only that it is a pointer.

> Maybe.  If font objects are kept alive, and face->font is supposed to
> be updated when the font object moves, by virtue of fix_face, then how
> come face->font ends up pointing to inaccessible memory in Helmut's
> recipe?

Inaccessible memory in my experience so far means that the corresponding
object has either been moved by MPS, or it has been "freed", by not
copying it.

So, as an ansatz, let's assume the font in question has been moved. It
would follow, I think, that it is not a face->font right? Because
otherwise the reference to the the font would have been traced. The
question would be where the reference to the font comes from?

>> (Not directly related, just to spread the info: This is necessary anyway
>> because I'm not using MPS in-band headers. With in-band headers, MPS
>> would itself do the calculations that I put into client_to_base, and
>> base_to_client. Base meaning the object start from the perspective of
>> MPS, and client meaning the object start from Emacs' POV. So, any
>> reference that Emacs holds is an interior pointer for MPS.
>
> Speaking about these two functions: are we sure struct member
> alignment will not get in the way of these calculations?  AFAIR,
> alignment of struct members is 8, even in 32-bit builds, is that
> right?  While sizeof (struct igc_header) yields 8 in my build, I
> wonder whether this is enough?

I pass wrt the struct alignment. The size of igc_header is 8 here too, 1
word.



reply via email to

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