ATBG: Why UTF-16?

I had a great time speaking at the Los Angeles .NET meetup Monday evening; thanks for the warm welcome from everyone who came out.

Today on the Coverity Development Testing Blog's continuing series Ask The Bug Guys I dive into the history of string representations in C# and Visual Basic to answer the question "why does C# use UTF-16 as the default encoding for strings?"


As always, if you have questions about a bug you've found in a C, C++, C# or Java program that you think would make a good episode of ATBG, please send your question along with a small reproducer of the problem to TheBugGuys@Coverity.com. We cannot promise to answer every question or solve every problem, but we’ll take a selection of the best questions that we can answer and address them on the dev testing blog every couple of weeks.

C# and VB are open sourced

For literally years now the Roslyn team has been considering whether or not to release the C# and VB analyzers as open source projects, and so I was very happy but not particularly surprised to watch on Channel 9 a few minutes ago Anders announce that Roslyn is now available on CodePlex.

What astonished me was that its not just a "reference" license, but a full on liberal Apache 2.0 license. And then to have Miguel announce that Xamarin had already got Roslyn working on linux was gobsmacking.

Believe me, we cloned that repo immediately.

I'm still mulling over the consequences of this awesome announcement; I'm watching Soma discuss Roslyn on Channel 9 right now, and Anders is coming up again soon for a Q&A session. (At 12:10 Pacific Daylight Time, here.)

I am also on a personal level very excited and a little nervous to finally have a product that I spent years of my life working on widely available in source code form. Since I always knew that open sourcing was a possibility I tried to write my portions of it as cleanly and clearly as possible; hopefully I succeeded.

Congratulations to the whole Roslyn team, and thanks for taking this big bold step into the open source world.

ATBG: Reordering optimizations

Last time on the Coverity Development Testing Blog's continuing series Ask The Bug Guys I discussed whether it was a good idea to remove a lock which protects an integer field. My conclusion was that it is not, because the lock prevents many potentially confusing optimizations. This week I follow up on that episode with an example where eliding locks on volatile reads and writes permits a surprising result.


As always, if you have questions about a bug you've found in a C, C++, C# or Java program that you think would make a good episode of ATBG, please send your question along with a small reproducer of the problem to TheBugGuys@Coverity.com. We cannot promise to answer every question or solve every problem, but we’ll take a selection of the best questions that we can answer and address them on the dev testing blog every couple of weeks.

ATBG: Can I skip the lock when reading an integer?

Today on the Coverity Development Testing Blog's continuing series Ask The Bug Guys, I answer a question that made its way to me from a Coverity customer: is it a good idea to remove a lock which only protects the read of an integer field? After all, that read is guaranteed to be atomic, so it seems safe. As is usually the case, the situation is unexpectedly complicated!1


UPDATE: A number of commenters have asked if marking the field volatile magically prevents reordering bugs. The specific problem with that proposal is that volatile reads and locks do not have the same semantics. A volatile read can be moved backwards in time with respect to a volatile write, and the x86 processor will actually do so, but a read, volatile or otherwise, cannot be moved backwards in time past the beginning of a lock. The more general problem is: we have a toy example that is greatly simplified from the real code, and therefore we don’t know what invariants the real code relies upon. Trying to deducing whether a real gun is safe by examining a toy gun is a dangerous proposition.

I have posted a follow-up article to address some of these concerns.


As always, if you have questions about a bug you've found in a C, C++, C# or Java program that you think would make a good episode of ATBG, please send your question along with a small reproducer of the problem to TheBugGuys@Coverity.com. We cannot promise to answer every question or solve every problem, but we’ll take a selection of the best questions that we can answer and address them on the dev testing blog every couple of weeks.

  1. Is "usually unexpected" an oxymoron?

Living with unchecked exceptions, part two

Thanks everyone who contributed to my earlier post about living with unchecked exceptions. There were over fifty comments in there that directly or indirectly addressed my questions.

The major takeaway here is: exceptions are a bit of a mess in C#. The language semantics and the organization (or lack thereof) of the exception hierarchy makes it hard to know what exceptions you should be catching and which you should be letting go. A lot of people left a lot of great comments but the one that resonated most strongly with me was

I think the whole notion of "handling" exceptions is a bit of a fool's game. I can probably count on the fingers of one hand the times where I've been able to catch a specific exception and then do something intelligent with it. 99% of the time you should either catch everything or catch nothing. When an exception of any type occurs, rewind to a stable state and then either abort or continue.

That's harsh but I think fair. Continue reading

Even more video

Here's another portion of the video interview that I shot over Christmas at Coverity headquarters in San Francisco.

In this bit I talk about the history of C#, how C#'s safety system is definitely a step in the right direction but not by any means a panacea, the most common defect patterns we find in C# code, the basic workflow for using the Coverity static analyzer, and finally a plug for this very blog. That's a lot to fit into seven minutes!

ATBG: How do exceptions interact with the "using" statement?

Today on the Coverity Development Testing Blog's continuing series Ask The Bug Guys, I answer a question I get quite frequently: what guarantees do we have about object disposal when the body of a using block is interrupted by an exception? The situation is rather complicated, it turns out.

As always, if you have questions about a bug you've found in a C, C++, C# or Java program that you think would make a good episode of ATBG, please send your question along with a small reproducer of the problem to TheBugGuys@Coverity.com. We cannot promise to answer every question or solve every problem, but we’ll take a selection of the best questions that we can answer and address them on the dev testing blog every couple of weeks.