Um, no

Dear non-English-as-a-first-language-speaking phishing attackers, let me point out all the ways that I know that this is not actually from PayPal. (Oddly enough gmail did not flag this as phishing, despite having a PayPal logo embedded in it and a link to what is obviously a phishing site.)

Dear Costumer, [A costumer is someone who makes clothing for actors. You meant “customer”.]

We need more information from you [missing period]

We need your help resoving [resolving] an issue with your account. To give us to work together on this, [this phrase doesn’t make any sense] we’ve temporarily limited what you can do with your account untill [until] the issue is resolved.

We need a little bit [of] information about you to help confirm you [your] identity [missing period]

Note: Please note that in 50% of cases you will receive this e-mail in the spam box, [comma splice] it is because of the increased security emailing services you use. [No, it’s because you’re criminals.]

UPDATE: This is deliberate! How astonishingly devious. See this transcript of On The Media and this Microsoft Research paper.

How much bias is introduced by the remainder technique?

(This is a follow-up article to my post on generating random data that conforms to a given distribution; you might want to read it first.)

Here’s an interesting question I was pondering last week. The .NET base class library has a method Random.Next(int) which gives you a pseudo-random integer greater than or equal to zero, and less than the argument. By contrast, the rand() method in the standard C library returns a random integer between 0 and RAND_MAX, which is usually 32768. A common technique for generating random numbers in a particular range is to use the remainder operator:

int value = rand() % range;

However, this almost always introduces some bias that causes the distribution to stop being uniform. Do you see why?
Continue reading

Fighting blind

No technology today. I’m spending this week in San Francisco at Coverity head office and did not have time to get blog posts in the queue ahead of time. But here’s a question I got from my friend Peggy a few days ago:

I watched The Return of the King on TV again last night and was left wondering: how it is that Gollum manages to get the Ring away from Frodo when Frodo is invisible?

Well that’s an amazing coincidence as I was watching TROTK on DVD with my housemate at I suspect the same time, even given the time zone difference. Clearly we are connected by some mysterious fifth sense! Continue reading

ATBG: method type inference with multiple interfaces

Today on the Coverity Development Testing Blog‘s continuing series Ask The Bug Guys, I take a question from an “Eric L”, who is confused about one of the subtle rules of method type inference despite having written the rule himself. My colleague Jon takes a question from a beginner C programmer about memory allocation.

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.

What I did on my long weekend

I had a delightful and relaxing American Thanksgiving weekend where I did not think about programming languages hardly at all. My general plan for the weekend was to (1) roast a turkey to feed 19, (2) make soup from the bones, and (3) do jigsaw puzzles with friends while eating soup.

Missions accomplished: (As always, click for larger versions.)

WP_20131128_001

WP_20131201_013

Many thanks to my crew of helpful friends who did most of the work putting Aragorn together.

I roast a turkey every year; people often ask me how to make it come out well. The answer is simple:

1) Brine the turkey for 12+ hours in a clean, food-safe five-gallon bucket with eight litres of water, half a kilogram of salt and two bottles of the cheapest chardonnay you can find.

2) Carefully follow the instructions in the Joy of Cooking. That is, truss the bird, roast it upside down at 325F for the first half, then flip it to roast breast side up for the second half. This solves the problem of undercooked legs and overcooked breast. Increase the temperature at the end, and measure the temperature inside the thigh. I find that going all the way to 175F is unnecessary; I’ve never had a problem with undercooked legs after the thigh gets to the mid to high 160’s. I stuff the cavities with apples and have someone else make the bread stuffing separately.

Next time on FAIC: Back to C# with another look at the method type inference algorithm.

The Thien baffle

As I mentioned in my interview with George London, I have too many hobbies. Long-time readers of this blog know that I started a second blog, Fabulous Adventures in Casting, because I was building a backyard foundry to learn how to cast aluminum.  Starting a new job on top of everything else was too much and so I decided to put that hobby on hold for a year or so, but I’ve started up again recently. And since this is not just my MSDN-hosted work blog anymore, I’m going to gradually move that content over here and occasionally post about stuff I’m doing that does not involve C#, like casting and woodworking. (UPDATE: As promised, those posts have been integrated into this blog; see the Foundry category.)
Continue reading

The A-star interviews

Tech blogger George London is running an interesting series of video podcasts wherein he interviews programmers about their jobs and then asks them to recommend other programmers to interview. On his ninth hop through the social network he managed to get to me. If you have 75 minutes to spare, here’s our long and rambling interview from the ukulele storage room in the new Coverity office. Subjects covered include Coverity, Roslyn, the Commodore SuperPET 9000, rocket ships, Zork, woodworking, sailing, monads and teaching trigonometry to youngsters, and many more.

The new Seattle office

As I mentioned earlier, we spent the past weekend moving the Seattle office from temporary space on the north side of the 42nd floor of Columbia Center to the south side of the 12th floor. I initially thought that this would be downgrading my fabulous view but no, it turns out to be an upgrade! Here’s the non-Mount Ranier side of the view from my office: (click for full size)

 
WP_20131121_001

Continue reading

ATBG: non-nullable reference types

Today on the Coverity Development Testing Blog‘s continuing series Ask The Bug Guys, a question I’ve gotten many times in person over the years but never blogged about: just how difficult would it be to retrofit non-nullability into the .NET type system? Pretty hard, 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.

Coverity analysis and FXCOP

This has been a crazy busy week and its only Tuesday. I spent the weekend helping set up the new Coverity office on the 12th floor of the Columbia Center — more on that on Thursday, after I’ve had a chance to take some photos — and schmoozing with my old team at Microsoft as part of the MVP summit. I am super-excited to be a C# MVP, though it is a bit odd to be on the audience side rather than the presenter side for the summit. “Thank you Eric for holding onto the microphone for us for the last half hour” was Anthony‘s wry comment after one marathon Q&A session yesterday. Old habits die hard.

One of the questions I’ve gotten frequently, both here at the summit and at other events, is how Coverity’s analysis of C# programs compares to FXCOP. My “Ask the bug guys” colleague Jon has just written an article about that very subject, so check it out. The short version: by design, they do not overlap at all. We want these tools to be complementary, not competitors. (And in fact you can import FXCOP warnings into Coverity Connect to track them alongside of defect reports discovered by Coverity’s analysis.)