Re: Suspicious warning in W64 build

[Richard Copley]

On 8 September 2017 at 09:02, Eli Zaretskii <address@hidden> wrote:
>> Date: Fri, 08 Sep 2017 09:49:44 +0300
>> From: Eli Zaretskii <address@hidden>
>>
>> OK, I will commit that change, then.
>
> Done.
>
>>
>> Yes, I've seen this and have a fix for it.
>
> Pushed to master.

Thanks for taking the time. Would you mind also suppressing warnings
from find-file-noselect when called from autoload-find-generated-file,
please, if you don't object? I don't think it would be a cludge. It
seems logical to me.

BTW, to correct a couple of my mistakes and perhaps save others
confusion,

On 7 September 2017 at 18:52, Richard Copley <address@hidden> wrote:
>
> 18446744065119617024 is 1<<64.
> The other number is (1<<64) - (1<<33) - (1<<2).
> That's just crazy. It must be a GCC bug.

On 7 September 2017 at 20:50, Richard Copley <address@hidden> wrote:
>
> Hmm, actually now I notice that A>B in the quoted range [A, B]. That's
> not normal mathematical notation.

Actually,

A = 18 446 744 065 119 617 024 = FFFF FFFE 0000 0000
B = 18 446 744 073 709 551 612 = FFFF FFFF FFFF FFFC

A = 1111111111111111 1111111111111110 0000000000000000 0000000000000000
B = 1111111111111111 1111111111111111 1111111111111111 1111111111111100

A =  = 2⁶⁴ - 2³³ = (1 << 64) - (1 << 33)
B =  = 2⁶⁴ - 2²  = (1 << 64) - (1 << 2)

and indeed A is less than B.

As Paul said, to evaluate the "nglyphs * sizeof (WORD) * 2", since
"sizeof(WORD)" is of type size_t,

* convert nglyphs from int to size_t (by repeatedly adding or
subtracting one more than the maximum value that can be represented in
the new type until the value is in the range of the new type).

* multiply it by four.

Assuming 64-bit unsigned size_t and 32-bit signed int,
if nglyphs is -2³¹ (INT_MIN) the value of the expression is A
and if nglyphs is -1 then the value is B.

"Crazy" was too strong (not to mention insensitive) a word to use,
but I still can't see that GCC is justified to warn when an
expression's value _might_ be out of range based on operand types;
taken to extremes that would rule out "alloca((size_t)n)". So either
I'm still missing something, or there's a GCC bug, or the compiler
correctly deduced that a negative number is passed in. I'm probably
still missing something.