It doesn't really matter whether they have

    if (launch1 && launch2 && launch3) {
        launch();
    }

either because a single bit flip (of the code) could still cause a launch. You'd hope that it was at least stored in ROM and that ECC ensures that even if such a bit flips it does not lead straight to Armageddon.

There are some 'near miss' stories where a single switch made all the difference:

https://www.theatlantic.com/technology/archive/2013/09/the-s...

So I would not be all that surprised if there are equivalent single bits.

Obviously this anecdote is decades out-of-date, but my first boss’ PhD thesis is for an automatic small-airplane guidance system. I mean: as long as your plane was on a high speed ballistic arc and needed a guidance system that only ran for about 25 minutes.

The guidance system used mercury & fluidic switches, in case the small aircraft encountered a constant barrage of extremely large EMPs.

Hehe, that's the most 'between the lines' comment ever on HN, congrats.

It should in-principle be possible to write a branch where the code itself is single-bit-error resistant, in pseudo-machine-code something like:

  LOAD [launch1]
  COMPARE 0x89abcdef
  JUMP_IF_NOT_EQUAL [fail_label]
  LOAD [launch2]
  COMPARE 0x01234567
  JUMP_IF_NOT_EQUAL [fail_label]
  LOAD [launch3]
  COMPARE 0xfedcba98
  JUMP_IF_NOT_EQUAL [fail_label]
  BRANCH [launch_label]

You also need to ensure that launch_label and the location of the branch instruction are both more than one bit away from fail_label. You can duplicate the JUMP_IF_NOT_EQUAL instructions as needed - or indeed the whole block before the BRANCH - as necessary to ensure that.

Your comment is one of the reasons why I still believe assembly has its place, when it really matters what kind of instructions you put out this is the sort of control you want. What your high level language is going to dump in the instruction stream is totally invisible (and interpreted languages are not even up for consideration in situations like these).

I don't know about nuclear missiles, but on the Space Shuttle I think they had four duplicate flight computers, and the outputs of all of them would be compared to look for errors. (They also had a fifth computer running entirely different software, as a failover option.)

The Space Shuttle also had a HP-41C calculator with special software to help with manual flying in case of a general computer failure: https://airandspace.si.edu/collection-objects/calculator-han...

I wonder how viable that was for different stages in the flight.

There have been false alerts caused by single chip failures. 1980 there was nuclear alert in the US that lasted over three minutes.

Generally critical systems can't be armed without physical interaction from humans. It's not just computer logic, but powering up the system that can do the launch. It does not matter what the logic does as long as ignition system is not powered up using physical switch.

I watched this documentary when young, the computer thought it was all a game?

This is why any system that can cause physical harm should have hardware interlocks. A computer error can be bypassed with a physical switch.

For something like nuclear missile launch control you have redundant systems and hardware interlocks that require human intervention to launch.