https://bugs.exim.org/show_bug.cgi?id=2474

--- Comment #2 from Lucas Trzesniewski <[email protected]> ---
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.
-- 
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev 

Reply via email to