Except you can't trust function names either.<p>Remember the NSO iMessage exploit?[1] <i>copyGifFromPath</i> didn't really copy the GIF from the path.<p>At some point, you <i>do</i> 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 <i>all</i> of those things, if you can.<p>But, "don't trust comments" is a gross oversimplification. Perhaps "trust, but verify" is a better pithy saying.<p>[1] <a href="https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html" rel="nofollow">https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...</a><p>[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 <i>not</i> have been thoroughly audited, tested, and fuzzed, with a nice formal specification
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 <i>was</i> 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.<p>Or am I misunderstanding something?
Comments state intent, code states reality. If those do not match one of them needs to change.<p>When it comes to security no one should trust that intent matches reality.
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.
I don’t want comments, I want <i>commentary</i>. Every time I’m confidently wrong in a commit message - anything from the wrong bug ID to declaring victory prematurely - I wish I could go modify or amend it.<p>Commits need to be in a separate version tree from their commit messages.
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.)<p>Sort of a combination of a reverse github auto-pilot metric and checking how old a comment is based on it's surrounding code.<p>You could even syntax highlight based on how accurate it thinks it is like how down voted HN comments fade out.