5 ms·

> Str substring(Str s, ptrdiff_t i) The function has quite questionable implementation. It fails miserably for strings with length < i.

• Joker_vD 2y ago
  Only because every other Str-accepting function uses "s.len" instead of "s.len > 0" as the "is s non-empty" test. Still, this function is called only once, and in that call, its i argument is always <= length, so it's perfectly fine (it's only UB if you actually pass it a bad argument).
  • bvrmn 2y ago
    > Still, this function is called only once, and in that call, its i argument is always <= length, so it's perfectly fine (it's only UB if you actually pass it a bad argument). This very mindset is a source of bugs and vulnerabilities. The author has high marks from me on safety and "make it hard to use wrong" and it's quite surprising to see such code.
    • UncleEntity 2y ago
      Reminds me of the time I was chastised for adding a NULL check to keep <program> from segfaulting by the dev responsible for said segfault because crashing without even as much as a warning was "intended behavior". IIRC this was over reading a file from disk and just assuming it existed.
    • grandempire 2y ago
      Satisfying preconditions is a requirement to make functioning programs. The insanity would be assuming that every function is valid for the Cartesian product of all possible of its arguments. What he probably needs is an assert
      • Joker_vD 2y ago
        > Satisfying preconditions is a requirement to make functioning programs. > The insanity would be assuming that every function is valid for the Cartesian product of all possible of its arguments. Would it? That reminds me of a recent post on HN about proving the long (binary) division algorithm with Hoare's logic. It uses the "d > 0" precondition and proves that, indeed, the algorithm arrives at the required postcondition. However, the algorithm still terminates and produces something even when d == 0. What does it computes in this case? Is it useful? Should such questions even be considered?
        • grandempire 2y ago
          > Should such questions even be considered? Yes, a better understanding of the problem gives you a better understanding of the preconditions. Always ask if you have that right and weaken accordingly.
      • bvrmn 2y ago
        For this particular case it's trivial to fix substring function and extend possible inputs. It seems your proposition: "do nothing because it's futile". It's simply wrong.
        • grandempire 2y ago
          Will that make the function more useful? In general you can write better code when you can make assumptions. Code to handle every possibility is filled with error prone branching, that reduplicates effort at every function.
          • bvrmn 2y ago
            It would reduce number of assumptions, especially ones laying only in your head. Generally it's a good thing, isn't it? Literally large portion of C code bugs is due to broken assumptions. WTF man?
    • milesrout 2y ago
      This mindset is literally the way safe programs work. What do you think functions are? This isn't some 100k line long program where this function is used all over the place and code churns constantly so checking invariants in the function definition makes sense. It is called in one (1) place in a small program.
      • bvrmn 2y ago
        > This isn't some 100k line long program It could use `str*` functions without any issues then. Nul-terminated strings are perfectly safe with assumptions to follow. Anecdote: I fixed 3 reported segfaults and another 2 after fuzz-testing in a small 500 line lib. Original author had the same cowboy mindset about keeping all stuff in his head. It's always last words before getting into CVE database.
        • grandempire 2y ago
          > Original author had the same cowboy mindset about keeping all stuff in his head. Nobody is saying that. Name, document, and assert.
          • bvrmn 2y ago
            > It is called in one (1) place in a small program.
            • milesrout 2y ago
              How is that in his head? That is the code.
              • bvrmn 2y ago
                > That is the code. Good code consists of easy to use abstractions. In general Chris's blog is dedicated to poking bad abstractions and giving good examples. `substring` is objectively bad. You (and other commentators) literally arguing that keeping staff in the head or making some documentation or notes or forcing yourself or others check low level implementation details are better than making one trivial fix and forget about it. I find it really amusing.
• milesrout 2y ago
  Why would you do that? Is there any situation in which it is called in this program where that could be true?