wallstprog

Back in the late 90's, one of the largest financial services firms in the US was still running its order-routing network on PDP-11s. One reason was that the code relied on the physical layout of the RK05 disks. They had people around the country scouring salvage auctions for spare parts that were no longer being manufactured.

You are paying for gmail, in a coin that Google accepts: your personal information. It's not "free" ...

> Which reminds me: what is a good tool for analyzing / viewing a C++ programs call tree?

As already mentioned, perf can capture call stacks, but those are statistical samples, so not necessarily complete.

callgrind (https://www.valgrind.org/docs/manual/cl-manual.html) by contrast can capture all call-stacks.

kCacheGrind/qCacheGrind (https://kcachegrind.github.io/html/Home.html) can be used to view the output from either perf or callgrind. Sources for kcachegrind, including converters from perf, oprofile, etc., can be found at https://github.com/KDE/kcachegrind

Similar but different -- in the 70's Daryl Hall recorded a pretty "alt" album, which RCA refused to release because they were afraid it would freak out Hall & Oates fans (https://en.wikipedia.org/wiki/Sacred_Songs).

True story -- someone (not me) decided to initialize a C++ virtual class by defining a default ctor which does a "memset(this, 0, sizeof(*this))", then uses placement new to re-create the vptr.

Newer compilers complained more and more until gcc 8 which just silently ignored this awful hack -- no diagnostic, no error, just crickets.

Strictly speaking silently ignoring this atrocity is allowed by the standard, but it sure took a while to figure out. So be careful with code that "just works" even if it shouldn't.

Depends -- there are so-called "body shops" that only care about billable hours, and these are the worst.

But in general as a consultant your time is the product that the co. is selling. Never forget that.

Thanks -- good to know about clang, although it does appear that the most recent version supported is clang 7 (Ubuntu defaults to 10, and supports 11). That's to be expected with RH/Centos, which again is one reason why e.g., Ubuntu can be easier to work with.

I'm also not sure I've bought in to the way the devtoolset stuff works, by swapping symlinks around. AFAICT that means that only one version is available at any given time.

If you build and install your own tools, you can (and should) install them in a non-standard location -- once you do that, it's relatively simple to support multiple versions at the same time.

Although if it wasn't for the COW vs. SSO strings problem, I would have spent more time on the devtoolset approach, but the lack of true C++11-style strings was a deal-breaker for me. I would much prefer not to be building compilers, although once you've done it once, it's not too bad.

A couple of things:

- RH devtoolset doesn't support clang, only gcc

-The compilers installed with the devtoolset packages on RH/CentOS 6 & 7 do not support the _GLIBCXX_USE_CXX11_ABI flag -- the old ABI (COW strings) is the only one supported. See https://bugzilla.redhat.com/show_bug.cgi?id=1546704 and https://stackoverflow.com/questions/50836145/glibcxx-use-cxx... for more info.

> To my knowledge, neither Infer or Clang has ever been compared to other static analysis tools in an article similar to this.

I beg to differ: http://btorpey.github.io/blog/categories/static-analysis/

The one thing I really miss about Windows is the Visual Studio debugger -- it was frickin' awesome even back w/VS 2005 and I have to believe it's gotten better.

On Linux I use ddd, and while it's definitely quirky (in that weird X way), it works just fine. I would guess that many of the poster's problems have to do with Linux's mediocre GUI support in general. I've recently switched to doing development on Ubuntu (vs. RH/CentOS) and all the GUI stuff works much better in that environment, incl. ddd.

I haven't tried Eclipse's C/C++ debugger, but its Perl debugger (part of EPIC) is quite nice and works well on both Mac and Linux.

For instance, see this recent post about using TLA+ to find a concurrency bug in glibc's implementation of pthreads:

https://probablydance.com/2020/10/31/using-tla-in-the-real-w...

Interesting that the Java VM installs signal handlers for SEGV, rather than checking for null pointers: https://www.ateam-oracle.com/why-am-i-seeing-sigsegv-when-i-...

FWIW this technique is described in "Unix Network Programming" by W. Richard Stevens (http://www.kohala.com/start/unp.html) in section 6.1: "Passing File Descriptors"

Interestingly, Eno composed the startup sound for Win95: http://www.synthtopia.com/content/2015/08/24/the-coolest-fea...

Even more interesting is that Robert Fripp (a frequent Eno collaborator) composed the startup sound for Windows Vista: https://www.youtube.com/watch?v=B-LYZt2jisE

What happened to "forked from"?

It's not that simple -- as Churchill said about democracy: "It's the worst form of government ever invented -- except for all the other ones".

I switched to Mac almost 10 years ago, and I'm basically pretty happy with it. So when it looks like Apple is planning to screw it up, I get upset -- I don't want to switch again (it was a huge PITA), and there's nothing out there even remotely close.

We have the same issue, except in both directions -- we use open-source projects as part of our software, and have also open-sourced a component that we developed, so we need to be able to go both ways.

The following seems to be working reasonably well so far:

- Each component has its own internal repo (in our case, we happen to use BitBucket). This repo contains any bits that are either proprietary and/or specific to our environment, like build scripts, integration with internal CI, etc.

- The open-source part of the component is hosted in an external repo on GitHub.

- The internal repo includes the contents of the external repo using git submodules (https://git-scm.com/docs/gitsubmodules).

We use a convention re: branch names:

- For projects that we don't own, "staging" is where our changes go before being submitted upstream as PR's.

- For projects that we do own, "staging" represents the current development "HEAD" -- our internal "master" branch includes the "staging" branch from the external repo.

- In either case, once a change has been approved for production use, it is committed to a release branch that is used to drive production builds.

Git submodules have a couple of features that make this easier:

- Each branch in the internal repo has its own .gitmodules file, which identifies which branch to fetch from the external repo. The .gitmodules file is an ordinary text file, and is managed just like any other file in the repo.

- Updating the submodule code in the internal repo is done by recording the hash of the specific commit from the external repo. This lets us control precisely which code from the external repo is included in builds (either development or production builds), and also provides an audit trail.

We used subtrees initially, and if there's not much traffic back and forth between the internal and external repos that can work, but it breaks down quickly as the repo becomes more active.

For now, I'll just address the one point -- obsolete? NOT!

We've been working with ZeroMQ a lot over the past couple of years, and have gotten to know some of the maintainers -- we've been very favorably impressed by their ability and dedication.

Pieter Hintjens was the "voice" of ZeroMQ, and with his passing things have gotten a bit quieter, but no less active. (Just take a look at the commit log: https://github.com/zeromq/libzmq/commits/master).

I much preferred the original title of the post -- why change it?

+inf to BC: http://www.scootersoftware.com/

Pretty low-tech, but what we do is to create an md5 hash of the whole stack trace as a single string. Before hashing, we munge some bits to help make similar stack traces hash to the same value:

- remove file/line#

- omit the bottom (top) frame, which can be different between environments

- convert certain constructs to a common format (e.g., "unknown module" (clang) to "???" (valgrind)

- translate "func@@GLIBC_version" => "func"

This works well enough in practice for our purposes (identifying regressions and suppressing specific reports from valgrind/Address Santizer).

We also maintain a xref between md5 hash and full stack trace.

From "Zen and the Art of Motorcyle Maintenance" (https://archive.org/details/ZenAndTheArtOfMotorcycleRepair-R...)

> "But they’re from the factory," John says.

> "I’m from the factory too," I say "and I know how instructions like this are put together. You go out on the assembly line with a tape recorder and the foreman sends you to talk to the guy he needs least, the biggest goof-off he’s got, and whatever he tells you. ..that’s the instructions. The next guy might have told you something completely different and probably better, but he’s too busy."

> They all look surprised. "I might have known," DeWeese says.

Another very interesting take on this from Andrei Alexandrescu:

https://youtu.be/WjTrfoiB0MQ

https://github.com/CppCon/CppCon2015/blob/master/Presentatio...

"There are no stupid questions, only stupid people."

Sorry -- couldn't resist ;-)

I wrote a few posts on this topic that may be helpful: http://btorpey.github.io/blog/categories/static-analysis/

If Jenkins works for you, great. It does seem to support both clang and cppcheck, although not PVS-Studio (which is one of the better tools out there in my experience).

Personally, I'm happier with plain old text files that can be manipulated with awk, grep, etc., can be databased if needed (since they're csv files) -- and can also be compared using my all-time favorite software, Beyond Compare. (http://btorpey.github.io/blog/2013/01/29/beyond-compare/).

I think one of the unstated problems with static analysis is just keeping track of the results. I know that when I started working with these tools, it was a huge PITA just dealing with the various output files.

That's why I created tools to convert the output from different tools into a common CSV format that can be databased and used to compare output from different tools, or from different versions of the code (e.g., after fixing errors reported by the tools).

These tools currently work with cppcheck, clang and PVS-Studio and can be found here: http://btorpey.github.io/blog/categories/static-analysis/

Just a quick reminder -- if you want people to actually read your stuff, medium is the wrong place.

There is no way I'm signing up for whatever it is they want you to sign up for.

"Those who do not learn history are condemned to repeat it".

I came up writing code in BAL, COBOL, PL/1 and a bunch of other non-OOP languages, and those who think procedural programming is better have probably never done it. The starting point for OOP, at least for me, was the splendid book "Reliable Software through Composite Design" by Glenford Myers, which was the first to study coupling, cohesion and other techniques that lead directly to OOP. This book still maintains a position of honor on my shelf, and I strongly recommend it for anyone doing software development. (You can get a pdf from https://archive.org/details/reliablesoftware00myer or buy your own hard-copy at https://www.amazon.com/Reliable-software-through-composite-d...).

Now, crappy programmers can write crappy code in any language, just as good programmers can write good code in any language -- the prevalance of crappy code speaks more to the numbers of crappy programmers than crappy languages. I would suggest that OOP enables crappy programmers to write code simply because without OOP crappy programmers wouldn't be able to write any code at all.

When functional programming is able to provide performance on a par with non-functional programming, we can talk about it. Until then it is a curiosity, but not ready for prime-time.

To paraphrase Winston Churchill's comments on democracy: "OOP is the worst programming paradigm ever invented -- except for all the other ones".

I've had little success with that in the past -- I've submitted patches for both valgrind and AddressSanitizer which have gone nowhere. (For the record these are https://bugs.kde.org/show_bug.cgi?id=393926 and https://reviews.llvm.org/D46546 -- feel free to upvote them!)

I suspect the same would happen with glibc. To be fair, the maintainers for these packages have a lot on their plates, and tend to pay more attention to submitters who they see often, so one-shots like these just don't bubble up to the top.