CppCast - Difficult Bugs

Episode Date: December 12, 2019

Rob and Jason are joined by Satabdi Das. They first discuss a new Visual Studio update and an article written by Bjarne Stroustrup. Then Satabdi talks about debugging and why it's beneficial to write or give conference talks on difficult to fix bugs, she also talks about her work on a hardware emulator and static analyzers. News Visual Studio 2019 16.4.0 Released How can you be so certain? Bjarne Stroustrup Indicators: Activity Indicators for Modern C++ Links CppCon 2019: Satabdi Das "A Series of Unfortunate Bugs" How to debug long running programs Hack && Tell Boston The Recurse Center Sponsors Write the hashtag #cppcast when requesting the license here One Day from PVS-Studio User Support JetBrains

Episode 226 of CppCast with guest Shatabdi Das, recorded December 12th, 2019. Sponsor of this episode of CppCast is the PVS Studio team. The team promotes regular usage of static code analysis and the PVS Studio static analysis tool. And by JetBrains, makers of smart IDEs to simplify your challenging tasks and automate the routine ones. Exclusively for CppCast, JetBrains is offering a 25% discount for a yearly individual license, new or update, on the C++ tool of your choice, C-Line, ReSharper C++, or AppCode. Use the coupon code JETBRAINS for CppCast during checkout at www.jetbrains.com. In this episode, we talk about a paper from Bjarne Stroustrup.

Then we talk to Shatabdi Das. Shatabdi talks to us about debugging and her work on emulators and static analyzers. Welcome to episode 226 of CppCast, the first podcast for C++ developers by C++ developers. I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how are you doing today? I'm doing okay rob uh back from my trip that involved code dive and speaking at the avast c++ users group in prague and speaking at an ea special event plus a bunch of training in bucharest and czechia it's a long trip yeah certainly sounds like it uh we've talked about the c++ user group at Avast a couple times. That's the one HANA runs, right?

How was that? That was fun. They meet, at least at the moment, I guess, yes, I think all of their meetings are in their company's cafeteria, canteen, basically. So there's some free food and coffee and drinks and stuff available and it's a pretty comfortable venue and it was fun yeah well you settled in and ready to stay in colorado for the rest of the year i'm guessing i'm hoping to okay well at the

top of our episode i'd like to read a piece of feedback uh we got this tweet from Bowie saying, he's tweeting at both of us saying, I think exceptions and error handling would be an interesting topic for a CBBCast episode. Perhaps if you had two guests to represent different perspectives on the topic, it seems like whenever exceptions turn up in my timeline and entering discussion ensues. And this is actually a reply

to a tweet from Jonathan Mueller where he was asking people, I think, if you disable exceptions, what is your reasoning for disabling exceptions? Yeah. So, it's certainly, you know, we don't have too many episodes where we have opposing viewpoints on the same episode.

I don't think we've ever done that. Yeah, I'm not sure if we have either. Sounds risky. Might be. Might turn into a bit of a brawl. But we could certainly have more episodes just talking about exceptions. And I would love to have, you know, Herb on to talk more about it when he's actually ready to, like, really propose that feature. Right. Yeah.

Okay. Well, we'd love to hear your thoughts about the show. You can always reach out to us on Facebook, Twitter, or email us at feedback at cbcast.com. And don't forget to leave us a review on iTunes or subscribe on YouTube. Joining us today is Shatabdi Das. Shatabdi has over 10 years of experience in C++. Currently, she's working on a cloud-based high-performance file system in AWS. She has previously worked on Emulator, Parser, and Static Analyzer.

She's also one of the co-founders of Boston Hackintel, a fun meetup for programmers to showcase their work. Long back, she contributed to GNOME as an outreach intern. And not so long back, she spent three months at Recurse Center learning assembly, debugger internals, and distributed systems. Shatabdi, welcome to the show. Thank you. Thanks for having me here. What is the Recurse Center? It's an educational retreat for programmers who want to get dramatically better at programming. It's based in New York. So they run these batches, which can, I did the 12 weeks batch.

It's a totally unstructured, self-driven way of learning. It was one of my most important, I think it was the most important programming experience I've ever had. 12 weeks? Was that full-time, 12 weeks? Yes. So, I did 12 weeks full-time because I was in between jobs. So, I left my job in India, I moved to the US and I was yet to join a job here. So, 12 weeks but they run six weeks and um a full week too uh for the people who are working um so definitely i recommend it to anybody like go to it if you want to uh you know build something learn something new it sounds like summer camp for adults or yeah it's more like um it's more like uh writers writers

retreat i mean the creative uh they do have such retreats where they like go off and then um focus on their craft it's it's more like that that's kind of sound like fun yeah do you know if it's only in uh new york or do they have other locations yeah that, it's only in New York. Yeah, you have to be in New York. So I moved to, I stayed in New York for almost three months for this thing. So you have to be there, unfortunately. Sounds cool though. It does.

It's very cool. Okay, well, Shatabdi, we have a couple news articles to discuss feel free to comment on any of these and then we'll start talking more about what you've been up to and debugging okay sure okay so this first one we have is visual studio 2019 16.4 came out i think just earlier this week um and we got the release notes here, which is about everything in Visual Studio, not just C++. But some of the highlights for C++ are, I think this is the first version with C++ 17 complete standard library. And it's the first version that has the ASAN support,

which we talked about when we had the Visual Studio team on at CppCon. And technically, this news became out of date between the time that you put it in the show notes and now oh did they already release another update 16.4.0 came out on december 3rd that's one of the major changes 16.4.1 came out on december 10th which appears to be a couple of small bug fixes ah okay yeah they have a pretty rapid cycle it's great um but i actually did try out um upgrading to this because i wanted to see what the asan support was look like was looking like and i did have to upgrade my projects which is one of the questions i think we had amongst ourselves like could you use the c++ 15 or 17 compiler with this? And it looks like you do have to be using the 2019 compiler.

So I did have to make some changes to my project to get that working, and unfortunately could not fully get ASAN running yet, but I'm going to spend some more time on it. Anything else either of you wanted to call out with the new release? Well, one thing that stands out to me is there's a bunch of cves at the top security

advisories with git for visual studio allowing remote execution and it made me wonder because i didn't like get into any of these if these are git vulnerabilities that are affecting visual studio or are they specific to visual studio yeah huh yeah i didn't notice those i'll have to look into them i don't use the git extension that much myself though no i don't i can't not use the command line i like i actually use a git kraken when we had we had them on the show a while ago yeah oh right uh okay moving on we have an article from bjorn strewrup, a paper he sent in, and it's titled, How Can You Be So Certain? And I guess it's him kind of criticizing the current way the C++ committee is operating. I guess he thinks maybe things are going not in a great direction.

I don't know. What was your take on this article, Jason? Well, it seems like some things are going too fast and some things are going too slow. And I don't know. There's a couple of things that stood out to me. Like where did it go? No,

I'm sorry. I'm trying to find a specific passage in the document. Here we go. He says, I think we are far too slow for concepts and far too fast for the spaceship operator right which i really wonder like if there's just more to that story that or if it's you know if that's the end of it for the spaceship specifically i know bjarne thinks we are too slow with uh concepts yeah i i wonder what other members of the committee will think about this. I mean, obviously, Bjarne

pulls a lot of weight. And I know we also covered this paper he wrote maybe a year ago, the Remember the Vasa, where he kind of brought up similar objections with, you know, we're adding too many features, things like that. Shatabdi, what did you think about this paper? So I read it it so this is this was pure uh quite educational for me so i really don't have any opinion on it but um it was for me uh a peek of what's going on you know in the background so i i feel anybody who is um writing c++ should read more of them. And I, frankly, I did not read such papers. And when you shared that, this link, it was really an interesting

read for me, other than that, I really don't have any other comments on this. I do like he says, he summarizes up most people's attitude, which is totally true. I hear this all the time. C++ is too complex, we need to make it smaller, simpler and cleaner. And please add these two features. And whatever you do, don't break my existing code. Yeah, that is absolutely true. I think it is a relatively long read. So people who are listening to this might want to, there's a summary of bullet points on page six, where he goes over specific things and talks about like how most of these things,

the research for them was done in like the 60s and 70s and 80s. And it's not like it's any big surprise, like concepts and contracts. But I like, he makes this statement a couple of times in here. And he mentions operator dot, which the last time we talked about operator dot

had to have been four or five years ago, Rob. It's been a while. It may have been, yeah. It was in the lead up to C++ 17, I'm sure of it, at best. And he says the very first extension proposal was in 1980 for an operator dot. And then he says C++ is not complete without operator dot or equivalent. Oh, wow. I think that is interesting coming from Bjarne, because he has, I'm sure, very strongly held opinions as to what the language needs to be complete in his mind.

And if that's something that he's wanted for nearly 40 years, then yeah. Okay. Last article we have is actually a git repository and i hope this one looked kind of neat um it's called indicators and it is a uh like a progress bar and progress spinner library for command line apps um i just like watching this little gif of a in action with different progress bars. I mean, it looks like you can do some cool things. It includes having a rocket ship

launch from the Earth to the Moon. It's pretty neat. Oh, I missed that one. The usage also is quite simple and it feels like it should not be difficult to use this in the readme. I think somewhere in the readme he has mentioned

yeah i'm sorry i'm just watching the animation yeah it certainly looks very easy to use you know you just create a progress bar object and you can you know have fill up and set the color and all sorts of things that uh yeah and you just take you just call the tick i think that's what it's called, the tick function or something like that. Yeah, bar.tick. I don't know. I'm a sucker for anything that's pretty command line utilities, right? I don't know.

At some point, I'm going to sit down and I'm going to do some way overly complicated just console application that's got all of the things going on and remind you of like ide's from like the 90s or something where everything was text-based like that's i don't know it's it's fun this would be useful for that yeah okay well uh shatabdi uh you gave a talk at cpcon 2019 about debugging. And you point out in the talk that programmers spend a majority of our time debugging, but it's not something we've really talked about too much on the show or at other conference talks.

So I thought maybe we'd start off by going over what your talk was about. Yeah, so it was about, actually the talk was about how to get better at debugging, although it was named a series of unfortunate bugs because I used a series of bugs to drive my point. What could have done better or how can I get better at debugging? So, yeah, I mean, some of these bugs were the ones which I fixed

and I jotted them down. And a couple I heard from other developer friends, we are discussing how these interesting bugs surfaced and how they were debugged. You mentioned unfortunate bugs that are often avoidable. How do you think we should be going about avoiding writing more bugs? That's a million-dollar question, isn't it? So I feel I somehow, like, I came to realize this.

I mean, we cannot avoid bugs. It's just we can minimize the number of bugs and we can help ourselves to debug them faster or rather make the debugging process a little bit easier. For that, I think the standard set of guidelines apply. For example, have a set of good coding practices, talk about them, share them and make that culture as a part of culture of your team. Use, do code review, do not check in code without code review use tools for example sanitizers or static analysis tools

use them and make them part of your regular build process or maybe if you can't do that maybe if that's too costly then do that say once in a week or maybe every day after certain changes, you know. So just have them so that you can detect the bugs faster than your customer. Because it's not nice to have your customer report a bug and then try to fix, particularly in a C++ code where when you ship it to the customer, it's everything, you just strip it down. It's totally, it's compiled with O3, so it's very difficult to debug from there. So if I remember your words correctly, you said you were working on a particularly difficult bug at some point

and basically had to learn enough about the code to be able to figure out what it was supposed to be doing. Do you have any recommendations for how to quickly learn code or how to get up to speed with this code base that you need to now be solving bugs in? So actually, I think a lot of it depends on how well the code was written. Like in some cases, it's really not very difficult. But in particular, in that bugs case, it was really difficult because it was a dense code. So what I would suggest is sometimes the only way like I, I try keep on trying a few strategies, like sometimes you try and read the code, you know, just without executing it, if you like, try and read and then reason out, okay,

this is what is happening and talk to other people because I feel talking to other developers is also very important. Who knows or try to find out if there is a document. Sometimes that cannot help you. Then in that case, put it on a debugger and try and understand what's going on.

What's the execution flow or put simple print statements to verify your assumptions. Okay, this is what you're thinking. This is the execution flow. And this is the value we should be getting. Is that happening? I usually follow these three or a mix of these three, like talking to people, debugging, using a debugger,

using print statements, and then try and understand what's going on. Reading documents also. That's, it's interesting to me for you to mention, you know, putting print statements in there, because I feel like nothing makes me want to throw my computer across the room more than when I put in these debug statements, because I cannot figure out what the code is going on. And then the debug statements never print. And I'm like, are they going to standard error? Are they going being redirected to a file? Are they, is this code not executing?

And I just want to screw. Yeah, yeah, yeah. Sometimes like the code may be, particularly like if you're using printf or something like that, as bare bones as that, sometimes it does. But sometimes if you're using, I certainly, I don't know whether you're referring to this, but I have seen like using the existing log statements and they are going to somewhere and I don't know where they're going. It's a pain. It's a pain. You're like, force it to standard out now, please. Yeah, yeah, yeah, yeah yeah it's it's painful sometimes right uh you mentioned uh in the course of the talk towards the end of the talk

that you uh now i can't recall if you said that you actually did keep a log or you suggest keeping like a journal of your bug fixing can you just explain explain more about that? I do recommend it. Although I, so I usually what I do is if I fix something, particularly in case of debugging, if I fix something very interesting, and it took me a long time to debug that, I do keep a note. Oftentimes, I cannot, like I do not have enough times to make a good. Oftentimes, I cannot, like I do not have enough times to make a good blog post out of it, which will be useful for people because that takes effort.

But I do keep a note for myself. But having said that, I do not do that for every bug. Like there are some bugs which are like very trivial. You do not need to do that. I sometimes, what I did, did for example in my last job when i fixed uh particularly two difficult bugs uh one of them i actually blogged about and then

also talked at zipicon uh and another i did not but i wrote a post-mortem statement what was the bug how did i find what caused the bug uh and how did i. A small, very small post-mortem statement for both the bugs and sent it to the team, shared it across the team. And I feel doing that is very valuable, although it takes time. And it's very important to have a log. Otherwise, one, you forget it. And sometimes you'll be, oh, okay,

I may have fixed something like that. What was it? And then you forget it. And sometimes you'll be, oh, okay, I may have fixed something like that. What was it? And then you forget. So I think having that is important. Yeah, I really like that idea, because I mean, if you don't do this, otherwise the only thing you have is your Git commit history. And you could spend

10 minutes on a bug and have a one-line fix in Git. Or you could spend two days working on a bug, and it still might line fix in git or you could spend two days working on a bug and it still might wind up being just a one line fix exactly but uh you should have something to say like here's what went into that one line fix you know to refresh your memory and everything yeah and the stories are actually very interesting particularly the one of the bugs that i talked about in my talk was um um was a right shift, was an undefined behavior.

And the fix was really very simple. It was one line fix, but it took me like a month, close to a month to get to it because it was in a code which I didn't understand. The person who wrote it left it and it was a very well-performed, like he was trying to squeeze performance out of every line of that code. I don't know what, but anyway, so it was a very dense spaghetti code. So the process of how did I find it, that was really interesting. When you put that up on the slide, I was immediately like,

I don't trust shift operations i know there's like without any kind of checking because i know there's undefined behavior in every direction with it depending assigned unsigned whatever and overflow into the sign bit you know whatever and uh but you know that's almost cheating right because you say find the bug on these five lines of code versus you had to find the bug in the giant code base. Yes. And then I hear in that, like the person in the audience answer, I'm like, I know who

that was. Just enough picked up on the mic voices that you know well and can recognize. Yeah. Yeah. So is this like, because I had just been thinking with all of the travel I've been doing lately, that just taking a little bit more of a journaling attitude is not a bad idea. And then I saw your talk, and you mentioned this, and I was just out of curiosity, is this part of, like, are you the kind of person that journals things anyhow?

I, not always, like, not everything, but I try to. Like like if I not and this this doesn't always apply to debugging but suppose I learned something like something interesting which I didn't know I try to put it down now I'm not very organized about it that's one problem like sometimes I I added some stuff in my github notes but that's out of date and then sometimes I added some stuff in my GitHub notes, but that's out of date. And then sometimes I do like keep my own document in some Google Doc. So I should get more organized so that I can, you know, quickly access them when I need to. But I need to find out ways to get organized. You did mention blogging a couple times. And I also, if I had a difficult issue, would blog about it.

But I haven't done that in a few years myself. Do you keep a public blog available? Yes. So I wrote about both these bugs. Sometimes the problem with blogging is, I mean, you cannot just write, oh, okay, here's this bug, and this is how I fix it. That doesn't make a very interesting blog. Because when I write a blog, one is you always think, why are you doing it?

And then also you also tend to think, what are the readers going to get from it? So that way I try to make a blog in a way so that the readers can also get something out of it. So I did write about two of the bugs that I covered in my talk. But they're not like, like, they're not about, okay, this is the bug that I fixed. Okay. I have one further question, then from all of this, you said that you wrote up the idea of writing up a postmortem and I'm curious. So since a significant amount of the work that actually commit is for clients,

I will do this bug fix and then put the postmortem, you know, a couple of paragraphs basically just in the get commit log message. Okay. And I have no idea if that's a good idea, basically. So that's what I'm wondering. Like what, what are your thoughts on how to best communicate this postmortem to the other team members?

I think a good test of that is after one year, you revisit those logs. And can you understand them? Probably you can, because probably you will remember them. But my point is like, are they legible to others? Or maybe our other team members are understanding from your post-mortem report what happened and how did you fix it? And so that's a good test, in my opinion. Like, if I'm writing a post-mortem, I'm actually writing it for myself, my future self, and also for team members so that you can

think from that perspective. I'm starting to feel a little shame. I'm not putting enough into my commit messages. Yeah. You know what? It's not that I always do it. Sometimes I'll be really ashamed of my git commit messages.

Like, oh, I should have added like, I should have added more information. But then, yeah, I mean, sometimes you're in like, oh, you know what? This is a very good commit message. You're proud of yourself. I think that's life. You'll definitely see a difference between commit messages on clients where I'm being paid hourly or whatever and i and i want to make sure i clearly communicate exactly what i did to earn the money right now

versus my own projects where sometimes it goes they are the worst they are the worst because you're like nobody's watching so at least that's what plays on my mind. Nobody watching. So just, okay, update something. Fix a bug. One-liner. Well, technically, everyone could be watching if you're doing it on a public GitHub repo. But yeah. If it's a public GitHub.

So yeah, for me personally, it's like repo I'm being paid to commit to, and then public GitHub repo, and then private GitHub repo. Who knows what those commit messages are like? I wanted to interrupt the discussion for just a moment to talk about the sponsor of this episode of CppCast, the PVS Studio team. The team promotes the practice of writing high quality code, as well as the methodology of static code analysis.

In their blog, you'll find many articles on programming, code security, checks of open source projects, and much more. For example, they've recently posted an article which demonstrates not in theory, but in practice, that many pull requests on GitHub related to bug fixing could have been avoided if code authors regularly use static code analysis. Speaking of which, another recent article shows how to set up regular runs of the PVS Studio Static Code Analyzer on Travis CI. Links to these publications are in the show notes for this episode. Try PVS Studio. The tool will help you find bugs and potential vulnerabilities in the code of programs written in C, C++, C Sharp, and Java. We wanted to ask about some of the other stuff you've worked on, too.

In your bio, you mentioned an emulator platform. Yes. So I worked in my last job. That was actually my last job. In fact, I was in that job when I gave the talk at CppCon. So it's an emulator for chip designs. So the emulator would take a chip design, which is usually represented in a high-level design language,

say very low, system very low, chip design, which is usually represented in a high-level design language, say Verilog, System Verilog. And it would emulate the design on a custom hardware. And usually the chip design companies, they use the emulator to verify their design or, say, to run, say, if it's a processor, you can boot up Linux, you know, or develop embedded software while the chip design is still going through. Their designers are still iterating on the design. So, about your emulator. So, make sure I understand, you are emulating in software a Verilog design?

No, it's emulating in custom hardware, actually. So, you think of the FPGAs? So, basically, you can program the FPGAs. So, suppose you take the SoC design, which

can be anything, say a processor. And you can program the FPGAs with that design and run it. It will run much slower, meaning suppose it's the performance of the design in gigahertz or hertz, that can be like order of magnitude slower, but it would still run. And you can verify, say, say suppose i can take a very small example say suppose it's a processor and it should it's a uh you should put up say linux

on it so your you can run the design on an emulator and you can put up linux on it but the thing is it it will be a it will be a very painful process because since the SOSs are much faster, but when you're emulating it on an FPG or any kind of custom hardware, the speed becomes very slow. So it's really difficult to actually put up a Linux, but it can validate your chip design that, okay, it's doing what it is expected to do.

Okay. And the chip design companies, they have very different kind of test setups to test their chip designs. So since I basically know nothing about this process, did you work on then software that translated the Verilog into something that could be written to FPGA? Yes. So you can think of it as a compiler toolchain, which takes the design and transforms it. And in the end, eventually it produces a binary, which can be loaded to the FPGA. So I worked in the software. So it was written in c++ and it's it's on linux because usually the chip

design companies they run this kind of verifications on linux platform so what i did was i worked on the scheduler part of it why it is a scheduler because a design any electronic design that has signals which are like some input signals and some output signals and the signals are traversing through the design right like that you pass a signal and that something happens and some transformations happen and you get some output as a signal um so it's actually when you have a large design and you're loading it on an emulator, you have to partition the design because the chips on the emulator, they are much smaller in capacity than the actual design. So you cannot load like you cannot load a single design on a single chip on the emulator. So you partition actually. So that essentially is a graph partitioning problem because you can represent all these designs as a graph actually okay so and then when

you partition the design you have all these partitions then the signal there is like you have to um you have to abide by certain constraints of the design like certain timing constraints any other kind of constraints and there you have to schedule those signals like you can think of it as the closest example i can give to you is like a pipe system like a complex pipe system water is flowing and at some certain joints of the pipe system you're saying okay at this joint the water cannot flow before the water flows from the other joint or something like that, you know, like some timing related constraint. So the software part that I worked on that did all this scheduling on this graphs. Okay, so did I make sense? Because I always feel like, yes, shuffling signals between the partitioned parts of the design across chips and making sure everything has the signal when it expects to.

Yeah, so that was the like very simplification, oversimplification. But essentially, if you think the software was doing that, like it was, it was taking a, like for me, for my day to day job, I I was not really bothered about the hardware language or anything. My input was a graph, and I was doing certain operations on the graph. That was what the tool did. So did you, I don't know, use provability? I don't even know. Like some way to prove that the transformations you did on the graph were correct. Oh, we keep on, like, the thing is, there are test benches, like this design should

work correctly, like given this input, it should produce output. So those help you verify that the design is working correctly. So suppose if it's an AND gate, if you give one and one, it should always produce one. If it says zero and zero, it should always produce zero. So those kind of like, there's some test suite to prove that whatever we are doing, even after we are making all these changes,

the design is working fine. There's a test methodology. I heard someone mention at Indy C Tech Town for the first time. I'd never heard of it before. I think they called it something like hardware in the loop testing. And so they would have their black box, whatever it was supposed to do, and then they would feed software inputs to it and read the outputs from it. So would you actually have to write these designs then to the hardware and then test and verify that it was doing the same output that they expected output you can think of it that way like the like when you're

programming the fpga chips actually to do what a chip what a what a asic chip is actually because all these designs are asic so you're taking an asic chip design and putting it on an FPGA. So you can think of it that way also. And there are quite a few different methodology of testing. Like you have a mix of software and hardware. Like you are running some model on software. And then that software is interfacing with the emulator, the hardware, and then you're getting some output. So the companies they do, and also my company, my ex-company,

they used to have different kinds of solutions for these customers to help them validate their designs. So when you made changes on your code and committed it to the GitHub repository, did it get automatically built, pushed to a piece of hardware, and then let you know if it was doing the correct thing? Oh, it's... Or run through some specific thing. Yeah, sorry.

So it was not actually that automated. So it was the release process was I would push some code and we will do some verification. The QA will do some verification. And then we make a release. So that would be the software part of the release. And then that will, just like Visual Studio, you're getting some release of the software.

So we'll make the release and the customer will use them in their setup and then see what they're seeing. Okay, so release validation kind of. Yes, it was validation. It's in the domain of validation. Sorry, just very curious about this kind of thing. I've done some embedded work, but it's been a very long time. And it was always through college. I debated going and working for companies that did FPGA stuff and whatever,

but never did actually do that. It's actually called EDA. It's called Electronic Design Automation. And it's a very, very small industry riding on the back of semiconductor industry. I do not know the numbers, and this may be like very wrong numbers, but it's like maybe one-sixth of value of semiconductors.

So it's a very small industry, and there are like very few companies. Synopsys is one of them. Cadence is one of them. Mentor, my company that I used to workopsis is one of them um cadence is one of them mentor the my company that i used to work in is one of them now mentor is acquired by siemens business so siemens has also gone got into this business mentor and siemens i've heard of yeah uh synopsis i think everybody is i think more familiar because they come to cppcon and they they are now they have acquired coverity so um they are um so they i mean they have the other like software purely

software based business also but all of these companies they have solutions um in this field okay since you just mentioned uh coverity your bio also said that you once worked on a static analyzer? Yes. And the static analyzer was also for hardware design. So basically, it's actually called formal verification. So you formally verify. So without running the design, you are trying to guess what are the problems. So basically, you can write some assertions,

some assumptions about the design, and you are sort of trying to verify whether those are correct or wrong. So that work you can probably think pretty similar to what Coverity does for C++ code base. Essentially, it's a satisfiability solver, SAT solver. So what I worked on, not on the SAT solver part, but the transformation part where you take the design, which is, again, written in some high-level language like Verilog or SystemVerilog,

and you transform that so that in the end you get some equations, which you can run to the SAT solver, put into the SAT solver, and then see whether your assumptions are correct or not. Okay. So one other thing I want to ask you about is, in your bio you said you're the co-founder of the Boston Hackintel. What exactly is that group, and how is it different from a programming language user group? We talk about different C++ user groups all the time.

Right. So, okay, disclosure that we ran seven sessions last year, and this year all the co-founders have become very busy so and also it's a yeah and it's a perpetual problem to get you know get speakers for if any of you run meetup groups you'll you'll understand it's it's very difficult to get speakers like every session we will have a good like 15 to 20 you know attendees uh we will have free food, free beer, good space. Somebody would lend a space. But getting a speaker was so difficult. So it's a group where you come and you present, preferably open source project, anything that you hacked.

It can be a library. It can be anything. But we prefer open source projects. And you present it. You present it for the format was presented for five minutes. And then we open the floor for five minutes of Q&A. So we did see some very good presentations last year. But this year, everybody is busy.

And so maybe hopefully next year, we'll again, you know, we can start it again in Boston. Let's see. I did some training in Cambridge this year. So I'm pretty sure there are C++ developers out there, maybe even listening to this podcast. So how should they contact you

if they are interested in presenting? Oh, just join the meetup group and let us know. We would be more than happy to, at least I personally would be more than happy to start it again because it was such a fun meetup because people would like, somebody, I remember somebody presented, so that person, he put a camera out of his window and his house was on a traffic junction. So he trained the camera to detect how many cars violated the signals. It's really fun.

So people do a lot of different interesting things and uh i'd very much love to see such things you know um just join the meetup group and and say that you want to present and we'll we'll we'll take it from there 90 cars violated the traffic signals so it's more of a hands-on user group compared to just going in and discussing a topic? Yes. That type of thing? Yeah. It's like any project you have done.

It doesn't have to be as impressive or as hands-on as this one. But anything, like any library. For example, this indicator. If somebody has written an indicator and he wants to show it to the people, they can come and then say, okay, this is what I've done. That's fun. Yeah. So you mentioned several times now what company you were working for. What work are you doing now?

So right now I'm working in AWS and I'm working on FSx for Lustre. So Lustre is a high performance file system. AWS is providing it on the cloud. So that's my day job right now. Okay. Using C++? No, the Lustre is written in C. And it's an open source project.

And they don't use, the team here, they don't use C++. Okay. Well, Shatabdi, is there anything else you wanted to go over before we let you go today? No, I think it was really fun talking to you two here and also talking about emulators and parsers and static analyzers. Okay. Well, it was great having you on the show today. Thank you for having me. Thank you. Thank you.

Thanks so much for listening in as we chat about C++. We'd love to hear what you think of the podcast. Please let us know if we're discussing the stuff you're interested in, or if you have a suggestion for a topic, we'd love to hear about that too. You can email all your thoughts to feedback at cppcast.com. We'd also appreciate if you can like CppCast on Facebook and follow CppCast on Twitter. You can also follow me at Rob W. Irving and Jason at Lefticus on Twitter. We'd also like to thank all our patrons who help support the show through Patreon. If you'd like to support us on Patreon, you can do so at patreon.com slash cppcast.

And of course, you can find all that info and the show notes on the podcast website at cppcast.com. Theme music for this episode was provided by podcastthemes.com.