It is technically possible, but improbable enough that, in the absence of direct evidence to the contrary (in this case, a functional browser that doesn't have bunches and bunches of exploitable bugs in its JS engine), it may as well not be.
Is the software for an ATM switch that contains more than a million lines of code, runs uninterrupted for twenty years straight, and scales from 10gbit to 160gbit sufficiently complex for you?
(Not to mention that said software isn't available for public scrutiny, and as such I have to take the assertion that it is bulletproof with a grain of salt. I mean, even NASA has had braindead-stupid moments (failing to convert units properly? A casting error? Running out of space on the filesystem?)))
Now you appear to refuse to consider any examples that demonstrate the in-correctness of your claim. Why?
Would you care to amend your claim to restrict it only to JavaScript engines shipping in free-to-use web browsers?
What was meant was "for each <thing X that is done by complex software>, <a piece of software S> doing X correctly is improbable enough that the existence of any piece of software doing X correctly may be considered to be impossible unless there is a piece of software that hasn't been shown to do X incorrectly".
What was taken was "for each <thing X that is done by complex software>, <a piece of software S> doing X correctly is improbable enough that the existence of any piece of software doing X correctly may be considered to be impossible unless there is a piece of software that hasn't been shown to do <any thing Y that is done by complex software> incorrectly".
An important distinction.
Hopefully this makes things clearer.
Here's the thing:
Problems in software are productively classed by their complexity and difficulty. That is to say that if you have two tasks, each of equivalent complexity and difficulty, the software to solve one task is going to be just as expensive to write as the software to solve the other one. [0]
I argue that designing and writing the software system required to run a piece of high-traffic, high-performance, near-zero-downtime networking gear that actually meets its goals [1] is in the same class of difficulty as writing a performant JS engine that has no "exploitable bugs". [3]
[0] For the purposes of this discussion, the cost to write any software used as part of the solution to either task must be included in the analysis of the overall cost.
[1] If you don't consider the existence of at least one production instance of this system being in continuous use for a decade or more proof of its correct design and implementation, I really don't know what else would convince you. You're highly unlikely to be able to evaluate the correctness of the system via manual inspection. [2]
[2] I mean, if you were one of the handful of mutants in existence who could do this, you'd likely not be wasting time arguing on HN.
[3] Actually, for giggles, can you point to a handful of somewhat recent High or Critical severity CVEs for V8 when used in Chrome or Chromium? Remember that you've been laser-focused on the Javascript engine, so failures of things like the browser's sandbox, browser's chrome, or OS process isolation don't count.
(As for the V8 engine, see https://code.google.com/p/chromium/issues/list?can=1&q=Type=.... (Note that Google does not make severe recent bugs publicly available.))
If you're currently starting your career in software, you're sure to -one day- consider the topic in the same way that I do. It's the only rational way to think about it.
Regardless of how you think about the comparability of software complexity between software projects, your statement about the near-impossibility of creating correct complex software was a gross overstatement; one that you're still not owning up to. :)
That bug list is not a list of CVEs. What's more, it's a list of bugs for the entire Chromium project. I assume that you couldn't find any CVEs that only affected V8 the JS engine, as used in Chrome or Chromium. Their absence shoots a really big hole in the foundation of your primary claim, which was: "[There exists no] functional browser that doesn't have bunches and bunches of exploitable bugs in its JS engine.".