> From: Gavin Smith <[email protected]> > Date: Sat, 27 Feb 2021 20:12:05 +0000 > Cc: [email protected] > > 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.
