Hacker News Reader

Comment by _kst_ | Hacker News Reader

My point is that the risk of breaking existing code is the only reason not to apply this change to the standard.

My point is also that that's a valid reason to proceed carefully before making the change.

Even if the required source code changes are trivial or automatable, there will still be some variable amount of work required to deploy the changes. For a small program or library, maybe you can just rebuild and deploy. But for some projects, any change requires going through a full round of review, testing, recertification, and so on. For an update to code that controls a medical device or a nuclear reactor, for example, changing the code is the easy part.

I support the proposed change. I also support performing all due diligence before imposing it on all future implementations and C software.

View on HN

> But for some projects, any change requires going through a full round of review, testing, recertification, and so on.

If the new binary is literally identical to the last one which was passed validation, absolutely zero additional testing is required. It is a waste of resources to retest an identical binary (assuming everything else can be held constant of course, which obviously can't always be the case).

Actually sending our hypothetical refactoring to production would itself be a waste of resources anyway, since the binary is identical... you just skip it, wait for the next real change, and then proceed as usual.

All processes have exceptions, the "binary identical output" is an easy one if your leadership chain is capable of understanding it.

And to be clear, "binary" here could absolutely mean "entire firmware image". The era of reproducible builds is upon us, and it is glorious.

Sure if the new binary is bitwise identical to the old one, there's no need to release it.

But ...

"The era of reproducible builds is upon us"

What about old code built with old toolchains? And what about organizational policies that require a full round of testing for any update? How hard do you think it would be to change such policies?

No doubt there's some software that could easily be modified, recompiled, and released. My point is that there is also some software that can't.

And yes, in those cases the likely solution is to leave the code alone and continue to build it with the old toolchain.

The point is that the proposed change will break existing valid code, and that has a non-zero cost. I support Jens Gustedt's effort to find out just what that cost is before imposing the change. (And again, I hope the change does go into the next edition of the standard.)

Reply on news.ycombinator.com