> Date: Wed, 5 Apr 2023 11:31:12 +0200
> From: Patrice Dumas <pertu...@free.fr>
> Cc: Arash Esbati <ar...@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.
