8 ms·
> It’s hard, if not impossible, to avoid use-after-frees in a non-trivial codebase. Nice excuse. But just wholly untrue. Most of us have not had any of these f
by ncmncm 4y ago
> It’s hard, if not impossible, to avoid use-after-frees in a non-trivial codebase.
Nice excuse. But just wholly untrue. Most of us have not had any of these faults in years. Zero. I cannot even remember the last time I had one. Or even saw one.
It is just possible that it is particularly harder in the hackneyed dialect of C++ that Google coders are forced to use, but that is doubtful. The fault does seem to be particularly associated with Google, although old Mozilla code seems similarly afflicted.
It is probably connected with fooling with actual naked pointers, and transferring ownership according to more-or-less documented conventions, as opposed to never needing to document it because it is simply never done, and never needs to be done.
The skill level of Google's in-house coders, as for Microsoft's, has seen plenty of boosterism, but the numbers don't lie. Neither place is a habitual producer of code to brag about. Having worked there should not count in your favor in an interview.
- PoignardAzur 4y agoAlternate hypothesis: the likelyhood of accidentally writing a use-after-error is proportional to the scale of your codebase and the number of people who work on it. 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.
- ncmncm 4y agoThey are wholly unsurprising in C code. C offers literally nothing in the way of automation to eliminate the problem. But there is no excuse for writing C code today. "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.
- Arnt 4y agoGoogle's code base is really, really, really big. Someone once violated the NDA over beer to me about that, and it's amazingly big. I've seen large programs (that is, programs considered large by their full-time development teams) that contained fewer source lines than the Google search engine contains files.
- ncmncm 4y agoYes, "big, big, biggity-big". But not an excuse. Nobody forced hypertrophy on Google. Google has access to plenty of money to manage its problems. But size is not the problem, and access to money does not seem to forestall 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.
- Arnt 4y agoGoogle seems to manage its problems well; the search engine is very likely the world's biggest and most complex software system and its uptime is excellent. People who deliver that kind of uptime with such a complicated system may be assumed to know their work and do it well.
- ncmncm 4y agoYour assessment is at odds with their own statements. Google can be assumed to know the hole they are in. The mistake is thinking everybody else is in it too.
- ChrisLomont 4y ago>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=bugs+per+line+of+code&btnG= https://scholar.google.com/scholar?hl=en&as_sdt=0%2C15&q=bug...
- ncmncm 4y agoWe are not talking about bugs in general, but about a specific sort of bug common in C and Google code.
- SideQuark 4y ago>"Scale of your codebase" is a clever excuse, but it doesn't wash. Bugs scale with the size of the codebase, for every entity on earth.
- ncmncm 4y agoThe topic is, specifically, use-after-free bugs.
- ChrisLomont 4y agoAre you claiming that use-after-free bugs do not scale with codebase size? If so, please provide evidence, because that would be amazing.
- ncmncm 4y agoOf course they scale. Incidence X times scale factor W. W = Y^Z, size Y and scaling Z. But zero times W is zero.
- ChrisLomont 4y agoMy other post listed several thousand use after free bugs in hundreds of commercial programs, so your "zero times W is zero" claim is not accurate in practice.
- ncmncm 4y agoThe point is that the bug appears in many programs, particularly C and C-like whatever, and, apparently, Google programs. 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.
- ChrisLomont 4y ago
- the-lazy-guy 4y agoProbably, you rarely see these errors because you have never been a part of team making a comparably complex system which is used literally by billions of people and being exploited by multiple hackers. Also trying to implement certain algorithms and datastructures _efficiently_ often unfortunately calls for raw pointers. And writing the most used web browser certainly calls for trying to optimize things. If you think differently, please tell me how you would implement something as simple as a mutable tree, where each knows about it's parent.
- ncmncm 4y agoThere is a substantive difference between "rarely" and "never". The principle about trees, if you must use one -- they are very slow to walk -- is that you either use it, or mutate it, not both at the same time. Generally, instead of pointers to nodes as native objects, it is much better to have all the nodes in a more array-like container, and represent edges with indices. Then none own any others, and you can visit all the nodes, if you must, without following any edges at all. (Graphs, likewise.) You might keep all the nodes with one property in one vector, and the rest in a different one. If they have some unique identifier, that could be their index. Doing whatever your freshman Data Structures class taught, forever, is no way to code for a multi-billion dollar company.
- notacoward 4y ago> no way to code for a multi-billion dollar company ...because people coding for multi-billion dollar companies usually need to deal with concurrency if not outright parallelism. So people working at such companies don't code like first-year CS students (avoiding the sexist term) under an outdated curriculum. The real way to fail in that kind of environment is to keep giving advice suited only to a now-purely-pedagogical model of computation as a single sequential stream.
- ncmncm 4y ago> "avoiding the sexist term" Sexist term... "freshman"? You reveal that you had no intention of engaging honestly.
- Ygg2 4y ago> although old Mozilla code seems similarly afflicted. Mozilla invented a language to get around it. In my opinion it managed to improve the field of programming in a huge way. That said as long as C++ code relies on C code or programmer invalidates memory safety invariant somewhere you are just as safe as C code. I.e. not much.
- ncmncm 4y ago... and then abandoned it and fired everybody.
- Ygg2 4y agoThey abandoned Servo. Rust components are in Firefox, in Linux kernel, and others. Bolting on security after the fact, will never be as effective as building it from the ground up. And relying on humans to just not make mistakes is a fool's errand.
- ncmncm 4y agoHint: nobody here has suggested "relying on humans to just not make mistakes".
- Ygg2 4y agoYou implied when you said: > Most of us have not had any of these faults in years. Zero. I cannot even remember the last time I had one. Or even saw one. Implying it's an issue of just not making mistakes/getting better people/etc. So rather than relying on a strict borrow checker or a GC runtime, you rely that people won't make mistakes.
- ncmncm 4y agoI get that you have made that up. In fact, despite aggressive propaganda efforts, the borrow checker is not the only way to get static correctness. Making shit up does not lead to any valid conclusion. That I never have use-after-free or other memory errors is prima facie evidence that their absence is not a matter of "not making mistakes". We all make mistakes. Their entire non-occurrence must be attributed to other reasons. The main effect of your aggressive propaganda efforts is to destroy your credibility, and that of everybody who apes them. Congratulations.
- pjmlp 4y agoMaybe you can provide consulting to these companies like (Google, Microsoft, Facebook, NVidia et al), I guess they would pay your perfect C++ knowledge in gold.
- ncmncm 4y agoIt is, ultimately, a management problem. You cannot solve a management failing by adding technical people.
- pjmlp 4y agoWhich apparently everyone but a few enlightened folks suffer from, given the security reports from all major companies in the field, but what do they know.
- ncmncm 4y agoThey know they have management problems. News at 11.
- pjmlp 4y agoImagine how much money one could get with consulting rates about secure C++ coding practices that such corporations keep failing to adopt. None of the existing security assessment agencies has your foresight, big business opportunity lies ahead.