Announcement

Collapse
No announcement yet.

Torvalds Voices Thoughts On Linux Mitigating Unexpected Arithmetic Overflows/Underflows

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    Originally posted by ssokolow View Post

    Definitely. Warning fatigue is worse than no warnings because it'll desensitize people to the more significant ones.
    So true, I loved the first static analysers we got and they found a few genuine mistakes that had made it through code review, so we increased the warning level and added more static analysers, but now we just get thousands of false positives,

    Comment


    • #42
      Originally posted by josmat View Post

      I do not agree. I'm not a professional programmer, I have no diploma in computer science or any kind of engineering (my diploma is actually in music), just an amateur programmer and curious follower of Phoronix and the tech world. For me, wrap-around for integer arithmetic in computers is obvious. If there is people developing software that we use who don't know that, they're putting us in a risk. How can someone who works and gets paid for programming a computer don't know the basics of how a computer works?
      You'd be surprised how many programmers out there are only slightly better than script kiddies. Unfortunately.
      I see this very often. Good, or even great programmers in some area, a few months later I found them lacking in threading, DB or God knows what other area.

      Because of that, I will always go the route that makes thing more approachable. Though, after giving more thought to the matter at hand, it's not like you can get rid of overflows and replace that with properly working math. You run out of bits anyway, so the alternative would still be yet another hack/convention.

      Comment


      • #43
        Originally posted by carewolf View Post

        "(a+b < a)" on unsigned a and b, is only true when a + b overflow. It is an overflow test! So obviously overflow is expected and explicitly handled, an analyser complaining about a check EXPLICITLY testing for overflow as possibly overflowing IS BROKEN.
        And I still say that every straw on that camel's back is one step closer to C++'s inhuman mess of things to remember. For example, is it clear, intuitive, and obvious after a dozen refactors that an overflow test there is the correct thing to do? It depends on what the actual variable names are.

        Comment


        • #44
          Originally posted by ssokolow View Post

          And I still say that every straw on that camel's back is one step closer to C++'s inhuman mess of things to remember. For example, is it clear, intuitive, and obvious after a dozen refactors that an overflow test there is the correct thing to do? It depends on what the actual variable names are.
          Yes a sum of two positive numbers is never smaller than one of the input values. So the statement is either dead code or an overflow test. Which one should be obvious from what happens inside the branch statement. If it isn't you might need to fix the code, but that isn't really something a static analyser can tell, but it should not warn about overflow where the risk of overflow has been explicitly handled, this is the code an analyser should make you write, not what it should complain about.

          Comment


          • #45
            Here are my thoughts on this, and many similar, issues.

            1. To the young generation nothing is sacrosanct -- if they believe C standard is wrong they will want to change it, everyone using it for 4+ decades be damned. I say, if you want to be protected from overflows write your code in C# which does runtime checking for it and leave C standard and compiler alone for the adults in the room who can handle it just fine or just learn to deal with it like we do.

            2. They focus on irrelevant issues like this and make a lot of noise because they are trying to make their "conttributions" appear relevant -- it's all part of attention seeking behavior trained by growing up on Facebook, Instagram and Twitter coupled with total misunderstanding of the subject at hand. It's the same kind of people who want to change TOML file specification to allow INLINE table to SPAN SEVERAL LINES when there are already regular tables that can do that and allow deep nesting in it instead of just using JSON instead.

            3. All of this is a symptom of "knowledge at our fingertips" where everyone thinks they can do any task after 5 minutes of Googling or "talking" to ChatGPT. It was way better 4 decades ago when everyone knew their place and only worked on stuff they have been trained to do.

            TL;DR -- Let people who know about arithmetic overflows write kernel code in C while those who don't know AND don't want to learn stick to safe languages like C# or Rust and GUI / frontend programming.

            Comment


            • #46
              Originally posted by bug77 View Post

              You'd be surprised how many programmers out there are only slightly better than script kiddies. Unfortunately.
              I see this very often. Good, or even great programmers in some area, a few months later I found them lacking in threading, DB or God knows what other area.

              Because of that, I will always go the route that makes thing more approachable.
              What everyone advocating for "making things more approachable" (and calling those who oppose them elitists and gatekeeper dweebs) conveniently ignores is that by doing so they are actually advocating for increasing the number of potential issues they will have to handle in the future exponentially as the number of unskilled / untrained people their "inclusion" is enabling keeps growing.

              We shouldn't be striving to lower the requirements to the lowest common denominator -- we should be striving to get people trained to meet those requirements. If some of them can't pass it's not the end of the world -- there are so many other things they can do with their lives.

              Comment


              • #47
                Originally posted by coder View Post
                Try looking in the mirror, before calling others insecure. Your own insecurity is the main reason you can't refute my posts point-by-point, as that would force you to actually reflect on what I'm saying.

                Furthermore, if you really wanted to demonstrate your competence and superiority, you'd be making rational arguments instead of hurling insults at everything and everyone you don't like. Resorting to the discursive tactics of an angry school child paints yourself in a far worse light than anything I could probably say.
                Guess what, I am secure enough to ignore your problems. I have no need to help you. You are just a cockroach I step on, pardon my french. If you want my help, what are you offering?

                Comment


                • #48
                  Originally posted by sdack View Post
                  Guess what, I am secure enough to ignore your problems. I have no need to help you. You are just a cockroach I step on, pardon my french. If you want my help, what are you offering?
                  when your single contribution to a thread is insults then perhaps it's time for some self reflection? While I personally don't fully agree with coder:s position here, he is not the problem.

                  Comment


                  • #49
                    My idea is to write // unsafe in the previous line. This would instruct the compiler not to raise any alert and also indicate that the one who wrote the code was aware of what he was doing.

                    Comment


                    • #50
                      Originally posted by bug77 View Post
                      it's not like you can get rid of overflows and replace that with properly working math. You run out of bits anyway,
                      Python implemented infinite integer arithmetic directly into the language. Most of the time, it's complete overkill. However, I've found it quite useful on a handful of occasions. I don't think that justifies it, though.

                      Comment

                      Working...
                      X