Hacker News Reader

Comment by Wowfunhappy | Hacker News Reader

> (including changing comments).

Huh? I didn't watch, but practically speaking, how do you break something by editing comments? Let's assume it's an actual comment and not a shebang line or something.

View on HN

I didn't watch it either, but...

Does your language have exceptions? Do the exceptions support stack traces? Do those stack traces have line numbers? Well then...

    // old code: version 1.2.3
    if(problem1) throw new Exception();
    if(problem2) throw new Exception();

Meanwhile, we have client code that catches the exception and then inspects the line number to see whether it was caused by problem1 or by problem2.

(You may say that this is crazy and no one would do such a thing. Maybe so. But this at least proves that it's theoretically possible. Also, you'd be surprised at what some people will do.)

Anyway, we upgrade to the new code:

    // new code: version 1.2.4
    // Helpful comment here; no other changes.
    if(problem1) throw new Exception();
    if(problem2) throw new Exception();

And of course this comment messes up all the line numbers, at which point we can have anything from misleading error messages to system meltdown, depending on what the client code used the line number for.

I was pretty impressed with Microsoft's support system that would pull up the symbols from the release build that created a crash dump. It's not a good use of time to troubleshoot using some wrong version of the code that may or may not even have the same problem.

That's only if you consider line numbers as part of the public API, which would be crazy.

I'm guessing no one is crazy enough to consider line numbers part of the public API. And yet... I could imagine myself writing code like this if I were desperate enough, even though I would know perfectly well that my code would probably break the never next time I upgrade.

Sure, but that's because you know you've used a non-public API in which case semver has nothing to do with the conversation.

good point

Because someone in your (presumably massive) org had some code somewhere that was parsing the source itself looking for... something. (The story Googlers tell is a program looking for a specific line number in a program’s output.)

More on Hyrum’s Law: https://www.hyrumslaw.com/

You can break things by editing comments, but those things aren't, usually, part of the public API.

SemVer is a claim about the public API, not the total of behavior you could potentially observe and react to.

Another classic was (is?) V8 using the textual size of a function as a heuristic when deciding whether to inline it in the jit. So changing a comment could have a large performance impact.

Wouldn't it be so smart to exclude comments in the size calculation?

Hard to say! It seems obvious, but given it is so obvious there might be a good reason to not do that. For example, if 99.9% of JavaScript in the wild weighted by popularity is minified, this could be the right tradeoff.

Source code level reflection. Things like __LINE__ can change with new comments above them. An example is something like a logging statement that makes use of something like a line macro and a brittle test that matches against an exact logging entry.

Reply on news.ycombinator.com