Re: pdumper on Solaris 10

[Eli Zaretskii]

> Date: Sun, 15 Dec 2024 10:55:49 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: gerd.moellmann@gmail.com, emacs-devel@gnu.org
> 
> "Eli Zaretskii" <eliz@gnu.org> writes:
> 
> >     CC       igc.o
> >   igc.c: In function 'weak_hash_table_entry':
> >   igc.c:4102:16: warning: cast to pointer from integer of different size 
> > [-Wint-to-pointer-cast]
> >    4102 |       client = (mps_addr_t)entry.intptr;
> >     |                ^
> >   igc.c:4107:16: warning: cast to pointer from integer of different size 
> > [-Wint-to-pointer-cast]
> >    4107 |       client = (mps_addr_t)real_ptr;
> >     |                ^
> >
> > The warnings are real, because mps_addr_t is a 'void *', so a 32-bit
> > data type, whereas entry.intptr is EMACS_UINT, so an unsigned 64-bit
> > type.
> 
> Oh, sorry for causing those.
> 
> The intended behavior is to truncate the integer and use the 32 LSB
> bits, which is safe on the machines MPS is ported to, and is expressed
> using a cast to mps_addr_t.  So the code behaves correctly, but is
> incorrect because it causes a compiler warning.

What about the (hypothetical) case of big-endian systems?

> What's the preferred way of avoiding a compiler warning in this case?
> A simple double cast (first to uintptr_t, then to mps_addr_t) should
> work, right?

I'll defer to Paul (CC'ed), but my personal preference is also to
explicitly reset the ignored bits by bitwise AND.

> > However, profiling doesn't work, whereas it did
> > in the "normal" 32-bit build.  (Note that SIGPROF is emulated on
> > Windows, so maybe that emulation somehow causes this problem when wide
> > ints are used with MPS.)
> 
> Thanks for letting me know! That certainly sounds like a regression we
> should fix.  What kind of problem are we talking about?

The profile is (was) empty.

However, I repeated the test now, and I see that the profile does
work.  I guess yesterday wins my personal record of producing
irreproducible results: this one and the one with
completion-at-point-functions in another discussion.

Sorry for the noise.