Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You've just inherited a legacy C++ codebase, now what?

gaultier.github.io

Post reply on HN
Print view View original

201–210 of 356 posts

Re: You've just inherited a legacy C++ codebase, now what?

#201

Post by skissane »

hyperman1 wrote: post #132
dataflow wrote: post #100

Earlier quoted context omitted.

Step 0: reproducible builds (like you said) Step 1: run all tests, mark all the flaky ones. Step 2: run all tests under sanitizers, mark all the ones that fail. Step 3: fix all the sanitizer failures. Step 4: (the other stuff you wrote)

If we're going to visit the circles of hell, let's do it properly: Step -1: Get it under source control and backed up. Step -2: Find out if the source code corresponds to the executable. Which of the 7 variants of the source code (if any). Step -3: Do dark rituals over a weekend with cdparanioa to scrape the source code from the bunch of scratched cd's found in someone's bottom drawer. Bonus point if said person died…

Question: Why does some of the product source code look like it is the output of a decompiler?

Answer: Our office was in the WTC and was destroyed on 9/11. Luckily everyone got out alive, but then we discovered we had no off-site backups of the source code. In order to continue development, we had to retrieve the released binaries from our customers and decompile them to get back source code.

Re: You've just inherited a legacy C++ codebase, now what?

#202

Post by jchw »

charcircuit wrote: post #181
jchw wrote: post #116

Earlier quoted context omitted.

I agree that this helps, although I still think that in general, the default build should never do -Werror, since people may use other toolchains and it shouldn't surprise-break downstream (I'm pretty sure this is a problem Linux distros struggle with all the time..) If it does it only in your fully reproducible CI, then it should be totally fine, of course.

Changing other dependencies can also cause the build to break. The best thing to do is to use the dependencies the project specifies.

Technically changing literally anything, including the processor microarchitecture that the developer originally tested the code on, could easily cause a real-world breakage. That doesn't mean it should, though.

Most libraries not written by Google have some kind of backwards compatibility policy. This is for good reasons. For example, if Debian updates libpng because there's a new RCE, it's ideal if they can update every package to the same new version of libpng all at once. If we go to the extreme of "exact dependencies for every package", then this would actually mean that you have to update every dependent package to a new release that has the new version of libpng, all at the same time, across all supported versions of the distribution. Not to mention, imagine the number of duplicate libraries. Many Linux distros, including Debian, have adopted a policy of only having one version of any given library across the whole repo. As far as I understand, that even includes banning statically linked copies, requiring potentially invasive patching to make sure that downstream packages use the dynamically linked system version. And trust me, if they want to do this, they *will* do this. If they can do it for Chromium, they sure as hell can do it for literally any package.

There's a balance, of course. If a distro does invasive patching and it is problematic, I think most people will be reasonable about it and accept that they need to report the issue to their distribution instead. Distros generally do accept bugs for the packages that they manage, and honestly for most packages, by the time a bug gets to you, there is a pretty reasonable chance that it's actually a valid issue, so throwing away the issue simply because it came from someone running an "unofficial" build seems really counterproductive and definitely not in the spirit of open source.

Reproducibility is good for many reasons. I do not feel it is a good excuse to just throw away potentially valid bug reports though. It's not that maintainers are under any obligation to actually act on bug reports, or for that matter, even accept them at all in the first place, but if you do accept bugs, I think that "this is broken in new version of Clang" is a very good and useful bug report that likely signals a problem.

Re: You've just inherited a legacy C++ codebase, now what?

#203

Post by gmueckl »

throwaway2037 wrote: post #179
throwaway71271 wrote: post #144

Earlier quoted context omitted.

> Wow I really hope this is hyperbole. I am sure its not, I dont have much experience as I have worked in only 3 companies in the last 25 years, but so far I have found no relation between code quality and company earnings.

> so far I have found no relation between code quality and company earnings. This! What matters is the market fit and customer experience. You can deliver a lot of value with average programmers working on a shitty code base.

I started to joke that in order to have a successful software startup, you need to essentially write the most godawful program code you can get away with. The money is much better spent on a good/aggressive sales strategy.

Elegant technology never wins on its own merits.

Re: You've just inherited a legacy C++ codebase, now what?

#204

Post by ta2234234242 »

hyperman1 wrote: post #132
dataflow wrote: post #100

Earlier quoted context omitted.

Step 0: reproducible builds (like you said) Step 1: run all tests, mark all the flaky ones. Step 2: run all tests under sanitizers, mark all the ones that fail. Step 3: fix all the sanitizer failures. Step 4: (the other stuff you wrote)

If we're going to visit the circles of hell, let's do it properly: Step -1: Get it under source control and backed up. Step -2: Find out if the source code corresponds to the executable. Which of the 7 variants of the source code (if any). Step -3: Do dark rituals over a weekend with cdparanioa to scrape the source code from the bunch of scratched cd's found in someone's bottom drawer. Bonus point if said person died…

Some people believe that if you read the C++ standard recreationally, it should be interpreted as a call for help, and intervention is required, putting the subject under 24/7 monitoring and physical restraints.

/s

Step -4: Get the version of windows and the compiler it was last known to compile with.

Re: You've just inherited a legacy C++ codebase, now what?

#205

Post by charcircuit »

jchw wrote: post #202
charcircuit wrote: post #181

Earlier quoted context omitted.

Changing other dependencies can also cause the build to break. The best thing to do is to use the dependencies the project specifies.

Technically changing literally anything , including the processor microarchitecture that the developer originally tested the code on, could easily cause a real-world breakage. That doesn't mean it should, though. Most libraries not written by Google have some kind of backwards compatibility policy. This is for good reasons. For example, if Debian updates libpng because there's a new RCE, it's ideal if they can update…

>For example, if Debian updates libpng because there's a new RCE, it's ideal if they can update every package to the same new version of libpng all at once.

It Debian is upgrading a dependency instead of a developer, then Debian should be ready to fix any bugs they introduce.

>then this would actually mean that you have to update every dependent package to a new release that has the new version of libpng, all at the same time, across all supported versions of the distribution

This is already how it works. All vulnerable programs make an update and try to hold off in releasing it until near an embargo date. You don't have to literally update them all at the same time. It's okay of some are updated at different times than others.

>Not to mention, imagine the number of duplicate libraries.

Duplicate libraries are not an issue.

>Many Linux distros, including Debian, have adopted a policy of only having one version of any given library across the whole repo.

This is a ridiculous policy to me as you are forcing programs to use dependencies they were not designed for. This is something that should be avoided as much as possible.

>by the time a bug gets to you, there is a pretty reasonable chance that it's actually a valid issue

That doesn't mean there isn't damage done. There are many people who consider kdenlive an unstable program that constantly crashes because of distros shipping it with the incorrect dependencies. This creates reputational damage.

Re: You've just inherited a legacy C++ codebase, now what?

#206

Post by Night_Thastus »

bluGill wrote: post #134
Night_Thastus wrote: post #19

Earlier quoted context omitted.

This adds additional problems. IE, Start replacing legacy C++ with Python, now debugging and following the flow of the code becomes very difficult.

If it is C++ I wouldn't think about python in most cases. Rust should come to mind. Ada, or D are other options you sometimes hear about.

Is it possible to integrate any of those while allowing seamless debugging? IE, step right from one into another? I've yet to see that happen.

Re: You've just inherited a legacy C++ codebase, now what?

#207

Post by Night_Thastus »

slingnow wrote: post #122
Night_Thastus wrote: post #43

Earlier quoted context omitted.

I'm just stating my experience. A single day, if they still have access to the codebase might be able to clear up some top-level concepts. But the devil is in all the tiny details. What is this tiny correction factor that was added 20 years ago? Why was this value cut off to X decimals? Why didn't they just do Y here? Why do we override this default behavior? It's tens of thousands of tiny questions like that which y…

I don't understand what you're saying. Clearly both types of meetings (one-off vs recurring) would be helpful. The one-off may save you days/weeks of research, but it seems like you're not satisfied with that unless you can answer every single minor question you might have across the entire codebase.

I'm saying that if you're maintaining a code base for years, a single day's explanations won't do much of anything. It's a drop in the bucket.

It's not a bad thing, and it's certainly good to do, but it's not a solution to the problem.

Re: You've just inherited a legacy C++ codebase, now what?

#209

Post by thrwwycbr »

hyperman1 wrote: post #132
dataflow wrote: post #100

Earlier quoted context omitted.

Step 0: reproducible builds (like you said) Step 1: run all tests, mark all the flaky ones. Step 2: run all tests under sanitizers, mark all the ones that fail. Step 3: fix all the sanitizer failures. Step 4: (the other stuff you wrote)

If we're going to visit the circles of hell, let's do it properly: Step -1: Get it under source control and backed up. Step -2: Find out if the source code corresponds to the executable. Which of the 7 variants of the source code (if any). Step -3: Do dark rituals over a weekend with cdparanioa to scrape the source code from the bunch of scratched cd's found in someone's bottom drawer. Bonus point if said person died…

Shouldn't it be step -3 to -1?

Re: You've just inherited a legacy C++ codebase, now what?

#210

Post by theamk »

Night_Thastus wrote: post #16

>worry not, by adding std::cmake to the standard library and you’ll see how it’s absolutely a game changer I'm pretty sure my stomach did somersaults on that. But as for the advice: >Get out the chainsaw and rip out everything that’s not absolutely required to provide the features your company/open source project is advertising and selling I hear you, but this is incredibly dangerous. Might as well take that chainsaw…

> It's dangerous for multiple reasons. Mainly it's a case of Chesterton's fence. Unless you fully understand why X was in the software...

If this is a function that no one links to, and your project does not mess with manual dynamic linking (or the function is not exposed), then it's pretty safe to remove it. If it's internal utility which does not get packaged into final release package, it is likely be safe to remove too. If it's a program which does not compile because it requires Solaris STREAMS and your targets are Linux + MacOS - kill it with fire.

(Of course removing function calls, or removing functionality that in-use code depends on, is dangerous. But there is plenty of stuff which has no connection to main code)

Post reply on HN