This is a sequel to my 2009 post about division of long integers.
I am occasionally asked why this code produces a bizarre error message:
Console.WriteLine(Math.Round(i / 6000000000, 5));
Where i is an integer.
The error is:
The call is ambiguous between the following methods: 'System.Math.Round(double, int)' and 'System.Math.Round(decimal, int)'
Um, what the heck? Continue reading
My next article about graph traversal is pre-empted by this breaking news; I’ll pick up that series again soon.
Yesterday morning a coworker forwarded to me an article about a recently patched security hole in Windows, and wondered if I had any thoughts on it. Oh, did I! I read about the exploit with an odd mixture of nostalgia — because I worked on the code in question back in the 1990s — and horror at how long this exploitable bug had been in Windows.
To be clear, I did not write the actual exploitable code; it predates my time at Microsoft. But I was worried while I was reading the article that it might turn out to be my bad! This is the second time that has happened to me, and it is not a pleasant feeling.
Coverity has a research team devoted specifically to security-impacting bugs, and they were kind enough to ask me to write up my thoughts for their blog. You can read about my guess at what the buggy code looked like here.
If you have examples of “missing restore”-style bugs — security-impacting or not — in real-world code in any language, I would love to see them. Please leave examples in the comments here or on the security blog. Thanks!
Today on the Coverity Development Testing Blog’s continuing series Ask The Bug Guys I take on a frequently asked question about generic type constraints and answer it with “dad jokes”. Check it out.
Today on the Coverity Development Testing Blog’s continuing series Ask The Bug Guys I’m turning it around and asking you to figure out why a seemingly correct and totally awesome implementation of random.Next has a serious bug. That’s right, it’s everyone’s favourite game, Spot the Defect! Can you figure out where I wrote a bug without running the program? Check it out.
I’m back! As always, I had a delightful August visiting friends and relatives in Canada. It was even more fun than usual because I’ve got a new boat. That is, a new-to-me boat; the boat is almost as old as I am. It’s a 1976 avocado-green Hobie 16. Here’s a video I shot of my first time trying it out: (I recommend watching it in HD resolution.)
Well enough chit-chat, back to programming language design. Today on the Coverity Development Testing Blog’s continuing series Ask The Bug Guys I’ll discuss how C++ is like a discredited theory of evolutionary biology and why that means you should not call a virtual method in a constructor.
Finishing off my series of questions people asked during my recent webcast that I didn’t have time to answer, some short Q&A: Continue reading
Continuing with my series of answers to questions that were asked during my webcast last week…
Do the “checkers” (algorithms that find specific defect patterns) find defects in unit testing code?
If you want them to, yes. Continue reading
Continuing with my series of answers to questions that were asked during my webcast on Tuesday:
The copy-paste checker example you showed was interesting. I’ve heard that NASA disallows copy-pasting in code because it is so error prone; is this true?
For readers who did not attend the talk: my favourite Coverity checker looks for code where you cut some code from one place, pasted it in another, and then made a series of almost but not quite consistent edits. An example taken from real world code is: Continue reading
Thanks to everyone who came out to my “webinar” talk today; we had an excellent turnout. Apologies for the problems with the slides; there is some performance issue in the system where it works fine when it is not under load, but when there are lots of people using it, the slides do not advance as fast as they should. Hopefully the hosting service will get it sorted out.
As I mentioned last time, the recording will be edited and posted on the Coverity blog; I’ll post a link when I have one.
We got far, far more questions from users than we could possibly answer in the few minutes we had left at the end, and far too many to fit into one reasonably-sized blog post, so I’m going to split them up over the next few episodes. Today:
What percentage of defects does the Coverity analyzer find that should have been caught by code review? Continue reading
Hello all, I have been crazy busy these last few weeks either traveling for work or actually programming with Roslyn — woo hoo! — and have not had time to blog. I’ve been meaning to do a short tour of the Roslyn codebase, now that it is open-sourced, but that will have to wait for later this summer.
Today I just want to mention that tomorrow, July 15th, at 8:30 AM Pacific Daylight Time, I’ll be doing a live talk broadcast on the internet where I’ll describe how the Coverity static analyzer works and what some of the most common defect patterns we find are. In particular I’m very excited by a new concurrency issue checker that looks for incorrect implementations of double-checked locking, and other “I avoided a lock when I should not have” defects. My colleague Kristen will also be talking about the new “desktop” mode of the analyzer.
If you’re interested, please register beforehand at this link. Thanks to Visual Studio Magazine for sponsoring this event.
If you missed it: the webcast will be recorded and the recording will be posted on the Coverity blog in a couple of days. The recording will also be posted on the Visual Studio Magazine site link above for 90 days.
Fabulous adventures in coding 