https://bugs.exim.org/show_bug.cgi?id=2474
--- Comment #2 from Lucas Trzesniewski <lucas.trzesniewski@???> ---
Thanks!
I tried to understand the 3rd case, and here's what I found:
- This function is not compiled on x64, that's why there's no warning on that
target
- The culprit seems to be the + operator applying a "usual arithmetic
conversion": Both operands are PCRE2_UCHAR16 in my case, therefore unsigned
short, and they get promoted to int. The result type of the + operation is also
int, which gets compared against a sljit_u32, which emits the warning.
Here's the Microsoft documentation page about usual arithmetic conversions in
C:
https://docs.microsoft.com/en-us/cpp/c-language/usual-arithmetic-conversions
The relevant parts are:
- Most C operators perform type conversions to bring the operands of an
expression to a common type or to extend short values to the integer size used
in machine operations.
- If none of the above conditions are met, both operands are converted to type
int.
Just to be sure this is not a Microsoft-specific quirk, I checked what the C
standard says, and it seems to agree. See paragraph 6.3.1.8 of
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1570.pdf - it contains
information similar to the Microsoft docs, but formulated differently. It
specifies that operands go through an "integer promotion" step which is
described in 6.3.1.1.2:
- If an int can represent all values of the original type (as restricted by
the width, for a bit-field), the value is converted to an int; otherwise, it is
converted to an unsigned int.
I think this explains why the left operand is converted to a signed integer,
and therefore the warning.
--
You are receiving this mail because:
You are on the CC list for the bug.
