Re: [PATCH] Silence compiler warnings with MinGW64

[Eli Zaretskii]

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

> For instance, is the
> following correct, or should long be replaced by something else?
>   long max_columns = (long) (intptr_t) k->value;

No, it's incorrect, because on 64-bit Windows 'long' is still 32-bit
wide, whereas a pointer is 64-bit wide.  That's why the compiler
emitted the warning that Arash reported in his environment in the
first place.

We could use 'long long' instead, but:

  . it might be less portable
  . on 32-bit platforms, it's overkill (and will slow the code even if
    'long long' does exist)

AFAIU, this kind of problems is exactly the reason for intptr_t and
uintptr_t: they are integer types that are wide enough for both for
pointers and for integers.