Does a C shift expression have unsigned type? Why would Splint warn about a right-shift?Why doesn't C have unsigned floats?Why does left shift operation invoke Undefined Behaviour when the left side operand has negative value?Is left-shifting a signed integer undefined behavior in C++03?Efficient unsigned-to-signed cast avoiding implementation-defined behaviorWhy is unsigned integer overflow defined behavior but signed integer overflow isn't?Why would the outcome of this shift left operation be deemed undefined?Arithmetic right-shift of signed integerWhy left shift of a negative signed value is not well-defined behavior?Is 1 << 31 well defined in C when sizeof(int) == 4Is “-1>>5;” unspecified behavior in C?
California: "For quality assurance, this phone call is being recorded"
what's the equivalent of helper in LWC?
How to detach yourself from a character you're going to kill?
Could a guilty Boris Johnson be used to cancel Brexit?
Can The Malloreon be read without first reading The Belgariad?
Alleged sexist comments charges presented toward me
Is American Express widely accepted in France?
What does the behaviour of water on the skin of an aircraft in flight tell us?
Strange math syntax in old basic listing
Does Peach's float negate shorthop knockback multipliers?
What is the intuition behind uniform continuity?
Why don't I have ground wiring on any of my outlets?
What is a simple, physical situation where complex numbers emerge naturally?
Is the capacitor drawn or wired wrongly?
Is it possible to kill all life on Earth?
Estimate related to the Möbius function
The deliberate use of misleading terminology
Asking bank to reduce APR instead of increasing credit limit
Explain Ant-Man's "not it" scene from Avengers: Endgame
Is there any Biblical Basis for 400 years of silence between Old and New Testament?
Slide Partition from Rowstore to Columnstore
Accidentally cashed a check twice
Order by does not work as I expect
What caused the tendency for conservatives to not support climate change regulations?
Does a C shift expression have unsigned type? Why would Splint warn about a right-shift?
Why doesn't C have unsigned floats?Why does left shift operation invoke Undefined Behaviour when the left side operand has negative value?Is left-shifting a signed integer undefined behavior in C++03?Efficient unsigned-to-signed cast avoiding implementation-defined behaviorWhy is unsigned integer overflow defined behavior but signed integer overflow isn't?Why would the outcome of this shift left operation be deemed undefined?Arithmetic right-shift of signed integerWhy left shift of a negative signed value is not well-defined behavior?Is 1 << 31 well defined in C when sizeof(int) == 4Is “-1>>5;” unspecified behavior in C?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;
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 >> E2isE1right-shiftedE2bit positions. IfE1has an unsigned type or ifE1has a signed type and a nonnegative value, the value of the result is the integral part of the quotient ofE1divided by the quantity, 2 raised to the powerE2.
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:
- Does the C standard make any claims about the type of the result of a bit-shift?
- Do compilers?
- If not, why might Splint be issuing this warning?
c language-lawyer code-analysis bit-shift splint
add a comment |
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 >> E2isE1right-shiftedE2bit positions. IfE1has an unsigned type or ifE1has a signed type and a nonnegative value, the value of the result is the integral part of the quotient ofE1divided by the quantity, 2 raised to the powerE2.
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:
- Does the C standard make any claims about the type of the result of a bit-shift?
- Do compilers?
- If not, why might Splint be issuing this warning?
c language-lawyer code-analysis bit-shift splint
4
Have you looked in the Splint source code whether it treats>>the same as the other binary operators? That would be a bug in Splint, and since the current version seems to be still the same as in 2007, I don't think much has happened since then.
– Roland Illig
Apr 14 at 7:41
3
github.com/ravenexp/splint/blob/…; the actual bug is in line 5775, which takes the wider type as the result instead of just taking the type of the left operand.
– Roland Illig
Apr 14 at 7:52
2
clang is a much better option than splint for static analysis these days, especially since it's been over a decade since splint was last updated.
– Shawn
Apr 14 at 8:27
@Shawn Clang doesn't do strict typedef checking. Nothing except Splint does (that I know of).
– detly
Apr 14 at 12:00
@Shawn Although thanks for reminding me about scan-build, I will now add it to my CI config!
– detly
Apr 14 at 12:08
add a comment |
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 >> E2isE1right-shiftedE2bit positions. IfE1has an unsigned type or ifE1has a signed type and a nonnegative value, the value of the result is the integral part of the quotient ofE1divided by the quantity, 2 raised to the powerE2.
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:
- Does the C standard make any claims about the type of the result of a bit-shift?
- Do compilers?
- If not, why might Splint be issuing this warning?
c language-lawyer code-analysis bit-shift splint
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 >> E2isE1right-shiftedE2bit positions. IfE1has an unsigned type or ifE1has a signed type and a nonnegative value, the value of the result is the integral part of the quotient ofE1divided by the quantity, 2 raised to the powerE2.
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:
- Does the C standard make any claims about the type of the result of a bit-shift?
- Do compilers?
- If not, why might Splint be issuing this warning?
c language-lawyer code-analysis bit-shift splint
c language-lawyer code-analysis bit-shift splint
edited Apr 14 at 16:05
Cody Gray♦
197k36389480
197k36389480
asked Apr 14 at 7:38
detlydetly
19.8k868126
19.8k868126
4
Have you looked in the Splint source code whether it treats>>the same as the other binary operators? That would be a bug in Splint, and since the current version seems to be still the same as in 2007, I don't think much has happened since then.
– Roland Illig
Apr 14 at 7:41
3
github.com/ravenexp/splint/blob/…; the actual bug is in line 5775, which takes the wider type as the result instead of just taking the type of the left operand.
– Roland Illig
Apr 14 at 7:52
2
clang is a much better option than splint for static analysis these days, especially since it's been over a decade since splint was last updated.
– Shawn
Apr 14 at 8:27
@Shawn Clang doesn't do strict typedef checking. Nothing except Splint does (that I know of).
– detly
Apr 14 at 12:00
@Shawn Although thanks for reminding me about scan-build, I will now add it to my CI config!
– detly
Apr 14 at 12:08
add a comment |
4
Have you looked in the Splint source code whether it treats>>the same as the other binary operators? That would be a bug in Splint, and since the current version seems to be still the same as in 2007, I don't think much has happened since then.
– Roland Illig
Apr 14 at 7:41
3
github.com/ravenexp/splint/blob/…; the actual bug is in line 5775, which takes the wider type as the result instead of just taking the type of the left operand.
– Roland Illig
Apr 14 at 7:52
2
clang is a much better option than splint for static analysis these days, especially since it's been over a decade since splint was last updated.
– Shawn
Apr 14 at 8:27
@Shawn Clang doesn't do strict typedef checking. Nothing except Splint does (that I know of).
– detly
Apr 14 at 12:00
@Shawn Although thanks for reminding me about scan-build, I will now add it to my CI config!
– detly
Apr 14 at 12:08
4
4
Have you looked in the Splint source code whether it treats
>> the same as the other binary operators? That would be a bug in Splint, and since the current version seems to be still the same as in 2007, I don't think much has happened since then.– Roland Illig
Apr 14 at 7:41
Have you looked in the Splint source code whether it treats
>> the same as the other binary operators? That would be a bug in Splint, and since the current version seems to be still the same as in 2007, I don't think much has happened since then.– Roland Illig
Apr 14 at 7:41
3
3
github.com/ravenexp/splint/blob/…; the actual bug is in line 5775, which takes the wider type as the result instead of just taking the type of the left operand.
– Roland Illig
Apr 14 at 7:52
github.com/ravenexp/splint/blob/…; the actual bug is in line 5775, which takes the wider type as the result instead of just taking the type of the left operand.
– Roland Illig
Apr 14 at 7:52
2
2
clang is a much better option than splint for static analysis these days, especially since it's been over a decade since splint was last updated.
– Shawn
Apr 14 at 8:27
clang is a much better option than splint for static analysis these days, especially since it's been over a decade since splint was last updated.
– Shawn
Apr 14 at 8:27
@Shawn Clang doesn't do strict typedef checking. Nothing except Splint does (that I know of).
– detly
Apr 14 at 12:00
@Shawn Clang doesn't do strict typedef checking. Nothing except Splint does (that I know of).
– detly
Apr 14 at 12:00
@Shawn Although thanks for reminding me about scan-build, I will now add it to my CI config!
– detly
Apr 14 at 12:08
@Shawn Although thanks for reminding me about scan-build, I will now add it to my CI config!
– detly
Apr 14 at 12:08
add a comment |
3 Answers
3
active
oldest
votes
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;
add a comment |
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.
add a comment |
The C99 through C17 standards say:
The integer promotions are performed on each of the operands. The type of the result is that of the promoted left operand.
Since value is an int it requires no promotion and the type of the "promoted left operand" is int, and the type of the result of << is the same.
C89/C90 says the same except with the word "integer" replaced by "integral".
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55673029%2fdoes-a-c-shift-expression-have-unsigned-type-why-would-splint-warn-about-a-righ%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
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;
add a comment |
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;
add a comment |
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;
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;
edited Apr 14 at 7:50
answered Apr 14 at 7:43
PSkocikPSkocik
36.6k65580
36.6k65580
add a comment |
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
edited Apr 14 at 16:01
Cody Gray♦
197k36389480
197k36389480
answered Apr 14 at 7:56
Roland IlligRoland Illig
31.7k106493
31.7k106493
add a comment |
add a comment |
The C99 through C17 standards say:
The integer promotions are performed on each of the operands. The type of the result is that of the promoted left operand.
Since value is an int it requires no promotion and the type of the "promoted left operand" is int, and the type of the result of << is the same.
C89/C90 says the same except with the word "integer" replaced by "integral".
add a comment |
The C99 through C17 standards say:
The integer promotions are performed on each of the operands. The type of the result is that of the promoted left operand.
Since value is an int it requires no promotion and the type of the "promoted left operand" is int, and the type of the result of << is the same.
C89/C90 says the same except with the word "integer" replaced by "integral".
add a comment |
The C99 through C17 standards say:
The integer promotions are performed on each of the operands. The type of the result is that of the promoted left operand.
Since value is an int it requires no promotion and the type of the "promoted left operand" is int, and the type of the result of << is the same.
C89/C90 says the same except with the word "integer" replaced by "integral".
The C99 through C17 standards say:
The integer promotions are performed on each of the operands. The type of the result is that of the promoted left operand.
Since value is an int it requires no promotion and the type of the "promoted left operand" is int, and the type of the result of << is the same.
C89/C90 says the same except with the word "integer" replaced by "integral".
answered Apr 14 at 7:47
hobbshobbs
147k15154242
147k15154242
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55673029%2fdoes-a-c-shift-expression-have-unsigned-type-why-would-splint-warn-about-a-righ%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
4
Have you looked in the Splint source code whether it treats
>>the same as the other binary operators? That would be a bug in Splint, and since the current version seems to be still the same as in 2007, I don't think much has happened since then.– Roland Illig
Apr 14 at 7:41
3
github.com/ravenexp/splint/blob/…; the actual bug is in line 5775, which takes the wider type as the result instead of just taking the type of the left operand.
– Roland Illig
Apr 14 at 7:52
2
clang is a much better option than splint for static analysis these days, especially since it's been over a decade since splint was last updated.
– Shawn
Apr 14 at 8:27
@Shawn Clang doesn't do strict typedef checking. Nothing except Splint does (that I know of).
– detly
Apr 14 at 12:00
@Shawn Although thanks for reminding me about scan-build, I will now add it to my CI config!
– detly
Apr 14 at 12:08