integer types

[Gavin Smith]

On Wed, Apr 05, 2023 at 01:08:41PM +0300, Eli Zaretskii wrote:
> > Date: Wed, 5 Apr 2023 11:31:12 +0200
> > From: Patrice Dumas <pertusus@free.fr>
> > Cc: Arash Esbati <arash@gnu.org>, bug-texinfo@gnu.org
> > 
> > On Wed, Apr 05, 2023 at 11:47:08AM +0300, Eli Zaretskii wrote:
> > > Those are real bugs: we should cast to inptr_t instead of long.
> > 
> > We already do that in some code, but we immediatly cast to another type,
> > defined in perl, like
> >   IV value = (IV) (intptr_t) k->value;
> > 
> > Is there a integer type we could cast to that represents integers that we
> > are sure makes sense to cast from intptr_t?
> 
> I'm not sure I understand the question.  Maybe if you tell why
> intptr_t doesn't fit this particular bill, I'll be able to give some
> meaningful answer.

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.  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'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.)

Could changing the type of this parameter then have effects on anywhere
add_extra_integer is called?  For example, the "max_columns" extra
value is set in 'end_line_starting_block':

    add_extra_integer (current->parent, "max_columns",
                               misc_args->value->contents.number);

The third integer argument has type 'size_t' which is converted to 'long'.
If we switch to using 'intptr_t' in add_extra_integer, then we have to
consider whether it's valid to convert from 'size_t' to 'intptr_t'.  If
not, then we may have to change the type of the 'number' fields in these
structs to 'intptr_t' too -- which may impact anywhere these struct types
are used, which is everywhere.

It's for those proposing this change to work through all these details.
One option may be to rewrite the code to use a union type.