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;








17















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?









share|improve this question



















  • 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

















17















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?









share|improve this question



















  • 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













17












17








17








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?









share|improve this 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?






c language-lawyer code-analysis bit-shift splint






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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












  • 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












3 Answers
3






active

oldest

votes


















17














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;






share|improve this answer
































    17














    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.






    share|improve this answer
































      2














      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".






      share|improve this answer























        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
        );



        );













        draft saved

        draft discarded


















        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









        17














        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;






        share|improve this answer





























          17














          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;






          share|improve this answer



























            17












            17








            17







            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;






            share|improve this answer















            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;







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Apr 14 at 7:50

























            answered Apr 14 at 7:43









            PSkocikPSkocik

            36.6k65580




            36.6k65580























                17














                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.






                share|improve this answer





























                  17














                  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.






                  share|improve this answer



























                    17












                    17








                    17







                    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.






                    share|improve this answer















                    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.







                    share|improve this answer














                    share|improve this answer



                    share|improve this answer








                    edited Apr 14 at 16:01









                    Cody Gray

                    197k36389480




                    197k36389480










                    answered Apr 14 at 7:56









                    Roland IlligRoland Illig

                    31.7k106493




                    31.7k106493





















                        2














                        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".






                        share|improve this answer



























                          2














                          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".






                          share|improve this answer

























                            2












                            2








                            2







                            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".






                            share|improve this answer













                            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".







                            share|improve this answer












                            share|improve this answer



                            share|improve this answer










                            answered Apr 14 at 7:47









                            hobbshobbs

                            147k15154242




                            147k15154242



























                                draft saved

                                draft discarded
















































                                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.




                                draft saved


                                draft discarded














                                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





















































                                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







                                Popular posts from this blog

                                Distance measures on a map of a game The 2019 Stack Overflow Developer Survey Results Are Inmin distance in a graphShortest distance path on contour plotHow to plot a tilted map?Finding points outside of a diskDelaunay link distanceAnnulus from GeoDisks: drawing a ring on a mapNegative Correlation DistanceFind distance along a path (GPS coordinates)Finding position at given distance in a GeoPathMathematics behind distance estimation using camera

                                How to get a smooth, uniform ParametricPlot of a 2D Region?How to plot a complicated Region?How to exclude a region from ParametricPlotHow discretize a region placing vertices on a specific non-uniform gridHow to transform a Plot or a ParametricPlot into a RegionHow can I get a smooth plot of a bounded region?Smooth ParametricPlot3D with RegionFunction?Smooth border of a region ParametricPlotSmooth region boundarySmooth region plot from list of pointsGet minimum y of a certain x in a region

                                Genealogie vun de Merowenger Vum Merowech bis zum Chilperich I. | Navigatiounsmenü