Re: texinfo-6.7.90 pretest

[Eli Zaretskii]

> From: Gavin Smith <gavinsmith0123@gmail.com>
> Date: Sat, 27 Feb 2021 20:12:05 +0000
> Cc: bug-texinfo@gnu.org
> 
> The current code is from commit 5057fbcc02e, where the ELEMENT * type is
> cast to a long in other parts of the change (instead of IV) (in
> handle_line_command in handle_commands.c).  If that cast doesn't give
> a warning, then changing the code in question to
> 
>               IV value = (long) f;
> 
> would be a good fix.

The above doesn't emit a warning in my MinGW build.  However, ...

> (Although I would have thought that was back-to-front
> as I thought a long on MS-Windows could only be 32 bits despite a pointer
> being 64 bits, while the IV type is supposed to big enough.

...exactly: mine is a 32-bit build, where both long and a pointer are
32-bit wide.  But in a 64-bit build on Windows long is 32-bit and a
pointer is 64-bit wide, so I think that would emit a warning.  Thus, I
think using intptr_t is a better fix.

> Otherwise, I'd be worried that intptr_t is not going to be defined on
> some platform or another.

You don't need to worry about that, I think, because we have Gnulib's
stdint.h in the tarball, and there's a configure-time test for
intptr_t, I think.