Re: integer types

[Eli Zaretskii]

> From: Gavin Smith <gavinsmith0123@gmail.com>
> Date: Wed, 5 Apr 2023 14:59:23 +0100
> Cc: pertusus@free.fr, arash@gnu.org, bug-texinfo@gnu.org
> 
> Might it be better to round-trip through intptr_t rather than through
> a pointer type?

Yes, I think this will be better.  Cleaner, too.

> > I think you are forgetting the endianness.  With at least one of the
> > two possible endianness possibilities, isn't it true that casting to a
> > narrower type can result in catastrophic loss of significant bits, if
> > you cast between integers and pointers, or vice versa?
> 
> I've never heard of that before.  So you are saying if you have a small
> integer (like 5) stored in a narrow integer type, cast this to a wider
> pointer type, and then cast it back to the same integer type, then
> something catastrophic happens?  How does that work?

If the pointer is to a narrower type, then dereferencing it will take
only part of the bits of the integer value.  Depending on the
endianness, that part could be the LSB (good) or MSB (bad).

> > If we don't want to change the type, we can assign the value to a
> > variable of the suitable width:
> > 
> >   void *elptr = value;
> >   add_associated_info_key (e->extra_info, key, elptr, extra_integer);
> 
> How is that different to the following?
> 
>     add_associated_info_key (e->extra_info, key, (void*) value, 
> extra_integer);

It avoids the problem with endianness, since all the significant bits
will be copied.