It's not like Google is uniquely bad at this. The Linux Kernel also suffers from memory safety error, and Google's Project Zero keeps fidning them in other projects.
It's not like Google is uniquely bad at this. The Linux Kernel also suffers from memory safety error, and Google's Project Zero keeps fidning them in other projects.
"Scale of your codebase" is a clever excuse, but it doesn't wash. The bigger your codebase, the less cowboy-ism you want. But Google seems to particularly foster it.
Insisting everybody else in the world has all your problems too can make your management failures seem excusable. But management failure can happen anywhere. It is evidently happening at Google. Software faults are a symptom. I don't know how they can fix the management problem that washed up as billions of lines of bad code.
I do know pretending won't help.
Google can be assumed to know the hole they are in. The mistake is thinking everybody else is in it too.
Which project of similar size doesn't have bugs? You seem to imply most don't, which is empirically untrue.
https://scholar.google.com/scholar?hl=en&as_sdt=0%2C15&q=bug...
And, if you really want to restrict to your goalpost moving subset, then go ahead and demonstrate that the above general trends are not trends in your subset. Because the literature on it disagrees with you.
So, to defend your claim "The mistake is thinking everybody else is in it too", care to show where "everybody else" is free from these bugs?
https://scholar.google.com/scholar?hl=en&as_sdt=0%2C15&q=use...
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=use+after+f...
This is the very first line from the very first post in the thread:
>> It’s hard, if not impossible, to avoid use-after-frees in a non-trivial codebase.
I just provided thousands of examples where it is true. To offset all that evidence can you provide, say, millions of examples where zero (your phrase) use-after-free bugs have been found?
>You reveal that you never had any intention of engaging honestly.
Honest engaging would be for you to provide evidence for a claim you made when asked. I provided extremely solid counter evidence from the result of many, many research teams.
So, care to honestly engage about your claim?
Bugs scale with the size of the codebase, for every entity on earth.
But zero times W is zero.
You could try to claim they are in all programs, but your selection-bias slip is showing. Programs they are not in (e.g. mine) are nowhere in your list. You can have no idea about the number of such programs. To pretend you do, as Google has done, is not honest.
Of course you could show that sampling is an invalid way to gather estimates of frequency, and rewrite all of statistics, but I suspect your high level C++ perfection is more time useful to you.
Me, on the other hand, trusts the aggregation of researchers over an internet commenter, even if they do have half of all comments in a topic.
Of course your mystery programs no one else can see provides you a way to claim such sampling is not representative. But since you made the claim, it is up to you to provide evidence.
I get that you have none except your anecdotal self-claims, which is certainly selection bias.
For example:
>Programs they are not in (e.g. mine) are nowhere in your list
I could point out you do mot have proof they are not in it; you just have not found one. Current tech on whole program correctness provers don't yet scale to codebases of this size, and absent that, you do not know your few programs do not have them, no matter how much you claim otherwise or try to code otherwise.
"To pretend as you do ... is not honest."