4 ms·

They 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

by ncmncm 4y ago

They 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 ago
Google'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 ago
  Yes, "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 ago
    Google 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 ago
      Your 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 ago
        We are not talking about bugs in general, but about a specific sort of bug common in C and Google code.
        ChrisLomont 4y ago
        From the literature on bugs, even this specific bug is common far beyond "C and Google code". 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+after+free+bugs&btnG= https://scholar.google.com/scholar?hl=en&as_sdt=0%2C15&q=use... https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=use+after+free https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=use+after+f...
        ncmncm 4y ago
        You reveal that you never had any intention of engaging honestly. 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.
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 ago
  The topic is, specifically, use-after-free bugs.
  - ChrisLomont 4y ago
    Are 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 ago
      Of 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 ago
        My 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 ago
        The 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

by ncmncm 4y ago

Arnt 4y ago

Google'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 ago
Yes, "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 ago
  Google 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 ago
    Your 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 ago
        We are not talking about bugs in general, but about a specific sort of bug common in C and Google code.
        ChrisLomont 4y ago
        From the literature on bugs, even this specific bug is common far beyond "C and Google code". 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+after+free+bugs&btnG= https://scholar.google.com/scholar?hl=en&as_sdt=0%2C15&q=use... https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=use+after+free https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=use+after+f...
        ncmncm 4y ago
        You reveal that you never had any intention of engaging honestly. 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.

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 ago
The topic is, specifically, use-after-free bugs.
- ChrisLomont 4y ago
  Are 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 ago
    Of 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 ago
      My 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 ago
        The 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