[HN Gopher] Don't trust comments
       ___________________________________________________________________
        
       Don't trust comments
        
       Author : xx_ns
       Score  : 31 points
       Date   : 2022-01-31 20:49 UTC (2 days ago)
        
 (HTM) web link (nns.ee)
 (TXT) w3m dump (nns.ee)
        
       | zatarc wrote:
       | Don't trust this comment.
        
       | xwdv wrote:
       | You can definitely trust comments on Hackernews more than other
       | sources such as Reddit.
        
       | monetus wrote:
       | 4 days between notification and propagation of the fix. Thank you
       | for poking around OP. Sanitizing your inputs isn't always simple.
        
       | spicybright wrote:
       | I kind of wish there was a verifier for function/statement
       | comments to flag inaccurate comments (besides interface
       | descriptions + general comment at the top of a function.)
       | 
       | Sort of a combination of a reverse github auto-pilot metric and
       | checking how old a comment is based on it's surrounding code.
       | 
       | You could even syntax highlight based on how accurate it thinks
       | it is like how down voted HN comments fade out.
        
         | xwdv wrote:
         | People don't care about accurate comments, they care about
         | comments they agree with.
        
           | tomcam wrote:
           | OK well you just rewrote my worldview. That observation can
           | goes deep as one wishes go go with it...
        
       | roylez wrote:
       | Yes, rst is more powerful. So powerful that it can cause CVE.
        
       | throw10920 wrote:
       | Except you can't trust function names either.
       | 
       | Remember the NSO iMessage exploit?[1] _copyGifFromPath_ didn 't
       | really copy the GIF from the path.
       | 
       | At some point, you _do_ have to trust that the kernel API 's
       | documentation (or whatever) is correct[2], simply because it's
       | physically impossible for you to exhaustively verify that each
       | piece of software you use (transitively) has correct
       | documentation and consistent semantics. That doesn't mean that
       | you shouldn't audit third-party code, do code reviews, write
       | tests, fuzz your code, and use static analysis and formal methods
       | - in fact, you should do _all_ of those things, if you can.
       | 
       | But, "don't trust comments" is a gross oversimplification.
       | Perhaps "trust, but verify" is a better pithy saying.
       | 
       | [1] https://googleprojectzero.blogspot.com/2021/12/a-deep-
       | dive-i...
       | 
       | [2] technically, if you did all of the above things, or found
       | other people that did them, then you wouldn't have to trust
       | documentation - but the vast majority of the time, most of the
       | software you encounter will _not_ have been thoroughly audited,
       | tested, and fuzzed, with a nice formal specification
        
         | jchw wrote:
         | On one hand, I agree.
         | 
         | On the other, this does feel a bit whatabouty. Because yeah,
         | you can't check the kernel code, but you can and should check
         | the code of direct dependencies. Not every time you do
         | anything, but certainly whenever there's something to be
         | feared. Running code against untrusted inputs from the Internet
         | is one of the few places that would justify "reverse engineer
         | the kernel to make sure it's safe" levels of concern, in the
         | right conditions.
        
       | longivitate wrote:
       | Especially this one.
        
         | capableweb wrote:
         | You're missing a `.. include :: ./arc-admin-credentials.json`
        
       | SahAssar wrote:
       | Comments state intent, code states reality. If those do not match
       | one of them needs to change.
       | 
       | When it comes to security no one should trust that intent matches
       | reality.
        
       | nathias wrote:
       | trust but verify
        
       | nerdponx wrote:
       | Can someone help me understand what actually happened here? As
       | far as I can gather, the comment in the code wasn't a lie, but
       | the overall system was complicated enough that there _was_ a way
       | for the thing-that-shouldn 't-happen to happen anyway. So the
       | docs weren't wrong, but there was a bug in the code that led to
       | incorrect behavior that deviated from the docs.
       | 
       | Or am I misunderstanding something?
        
       | wahern wrote:
       | Thus the hacker refrain, "lies, damned lies, and comments", for
       | which oddly I'm unable to find any examples despite having seen
       | it recited several times over the years. In fact, I believe I
       | came across that rephrasing before learning of Twain's famous
       | original. I always found it a more pithy justification for why
       | source code comments should only explain why, not how or what.
        
       ___________________________________________________________________
       (page generated 2022-02-02 23:00 UTC)