Re: integer types

[Eli Zaretskii]

> From: Gavin Smith <gavinsmith0123@gmail.com>
> Date: Wed, 5 Apr 2023 12:24:58 +0100
> Cc: Patrice Dumas <pertusus@free.fr>, arash@gnu.org, bug-texinfo@gnu.org
> 
> GNU coding standards (Info node (standards)CPU Portability):
> 
>      You need not cater to the possibility that 'long' will be smaller
>   than pointers and 'size_t'.  We know of one such platform: 64-bit
>   programs on Microsoft Windows.  If you care about making your package
>   run on Windows using Mingw64, you would need to deal with 8-byte
>   pointers and 4-byte 'long', which would break this code ...
> 
> We don't need to make changes to stop these warnings if it is going
> to be difficult to do so.

But is it, in fact, difficult?  Are there any problems with using
intptr_t, or (if we fear of it being unsupported on some platform)
with defining a macro that will yield 'long' on all platforms except
Windows, where it will yield 'intptr_t'?  (Since MinGW uses GCC as the
compiler, we can rely on 'intptr_t' to be available there.)

Of course, it is your call as a the Texinfo maintainer.  You can
decide that you don't care (but see below), in which case whoever
wants to build a reliable binary on Windows will need to make a simple
change locally.

> As I have said before, the warnings are not about real problems, as
> the integers in question are always small in magnitude in practice
> (e.g. you do not have a @multitable with millions of columns).

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'm concerned that trying to fix this may have the potential to require
> many changes throughout the code, which may not be worth it for the
> sake of silencing a harmless warning.  It may not be as simple as
> changing the types of a few variables or adding casts in a few places.
> 
> For example, for this warning:
> 
> > parsetexi/extra.c: In function 'add_extra_integer':
> > parsetexi/extra.c:124:48: warning: cast to pointer from integer
> >           of different size [-Wint-to-pointer-cast]
> >   124 |   add_associated_info_key (e->extra_info, key, (ELEMENT *) value, 
> > extra_integer);
> 
> 
> The 'value' parameter here has type 'long' which is then cast to a pointer.
> (I don't see how this causes a problem, actually, if 'long' is 32 bits
> and the pointer type is 64 bits.)

See above.

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);

> One option may be to rewrite the code to use a union type.

That can still lose bits, I think.