Does a C shift expression have unsigned type? Why would Splint warn about a right-shift?

Question

For the following program:

int main(void)
{
    int value = 2;
    int result = value >> 1U;
    return result;
}

...Splint 3.1.2 gives the warning:

splint_test.c: (in function main)
splint_test.c:4:18: Variable result initialized to type unsigned int, expects
                       int: value >> 1U
  To ignore signs in type comparisons use +ignoresigns

Splint seems to be claiming that an expression where a signed integer is shifted right has the type of an unsigned integer. However, all I can find in the ANSI C90 standard is:

The result of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has an unsigned type or if E1 has a signed type and a nonnegative value, the value of the result is the integral part of the quotient of E1 divided by the quantity, 2 raised to the power E2.

The primary target for this code is an embedded system with a mostly-C90 compiler. However, I'm interested in writing standards-compliant code. I have been testing on GCC and Clang in C99 mode so that restrict works.

My questions are:

1. Does the C standard make any claims about the type of the result of a bit-shift?
2. Do compilers?
3. If not, why might Splint be issuing this warning?

Answer 1

It's a bug in Splint. Splint wrongly assumes that the type of e1 << e2 is ctype_wider(te1, te2). The correct type would be just te1.

The buggy code starts here by using the same code path for the bitwise operators like &, | and ^, as well as for the << and >> operators.

The actual bug is at the end of that code, which assumes that for all these bitwise binary operators, the return type is ctype_wider(te1, te2).

I have opened a bug on Splint's GitHub issue tracker, referencing this question.

---

Update, February 2021:

NetBSD's lint says that in traditional C, the bitwise shift operators applied the usual arithmetic conversions to their operands:

    /* Make sure both operands are of the same type */
    if (mp->m_balance_operands || (tflag && (op == SHL || op == SHR)))
        balance(op, &ln, &rn);

Explanation of the code:

• tflag is the flag for checking traditional C programs, as opposed to C90 or C99
• mp->m_balance_operands is false for the bitwise shift operators, defined in this table, the b column in the middle
• balance performs the usual arithmetic conversions

This was a change in C90. The Splint code may thus have been correct for traditional C, maybe it just had not been updated for C90 or C99.

Answer 2

No. The standard says the type of a bitshift is the type of the left operand, promoted: 6.5.7p3

... The type of the result is that of the promoted left operand. ...

Your tool must be confused, inferring the type with usual arithmetic conversion, which applies to most binary operators but not << and >>.

You can also verify the type is int by inserting a _Generic-based type assert and observing that compilers accept it:

int main(void)
{
    int value = 2;
    int result = _Generic(value >> 1U, int: value>>1U); //compiles, the type is int
    return result;
}