Radical Refactoring: Breaking Changes

One of the most common sources of bugs is ambiguity: some too-subtle API change that’s missed in a library update and introduces a subtle bug, that finally only gets found out in the field. My answer to that problem is radical: make changes breaking changes — make sure the code just won’t compile unless fixed: the compiler is generally better at finding things you missed than you are.
Continue reading

Posted in Anecdotes, C & C++, C++ for the self-taught, Embedded software development, Radical Refactoring | Leave a comment

Improving the BrainF interpreter

As I wrote in a previous post, I wrote a BrainF interpreter in VHDL over a week-end. I decided to improve it a bit.
Continue reading

Posted in Software Development, VHDL | Tagged | Leave a comment

Radical Refactoring: Have the compiler to (some of) the reviewing

One of the most common sources of bugs is ambiguity: some too-subtle API change that’s missed in a library update and introduces a subtle bug, that finally only gets found out in the field. My answer to that problem is radical: make changes breaking changes — make sure the code just won’t compile unless fixed: the compiler is generally better at finding things you missed than you are.
Continue reading

Posted in Anecdotes, C & C++, C++ for the self-taught, Embedded software development, Radical Refactoring | Leave a comment

Writing a BrainF interpreter … in VHDL

I’ve written parsers and interpreters before, but usually in C++ or, if I was feeling like doing all of the hard work myself, in C.

Continue reading

Posted in Software Development, VHDL | Tagged | Comments Off

A different take on the “optimize by puzzle” problem

I explained the problem I presented in my previous post to my wife overt dinner yesterday. She’s a professor at law and a very intelligent person, but has no notion of set theory, graph theory, or algorithms. I’m sure many of my colleagues run into similar problems, so I thought I’d share the analogies I used to explain the problem, and the solution. I didn’t get to explaining how to arrive at computational complexity, though.

Continue reading

Posted in Algorithms, C++ for the self-taught, Software Design | Comments Off

Optimization by puzzle

Given a query routine that takes a name and may return several, write a routine that takes a single name and returns a set of names for which each of the following is true:

  1. For each name in the set, query has been called exactly once.
  2. All the results from the calls to query are included in the set
  3. the parameter to the routine is not included in the set

You may assume the following:

  1. Calls to query are idempotent1.
  2. There is a finite number of values for names.
  3. Names are less-than-comparable value-types (i.e. you can store them in an std::set) and are not expensive to copy
  4. query results never contain their argument2

Continue reading

  1. so you really do need to call them only once []
  2. i.e. for the case at hand, we’re querying a directed acyclic graph, so our first argument will never be seen in any of the query results, although any given value may appear more than once in query results []
Posted in Algorithms, C & C++, C++ for the self-taught, Software Design, Software Development, Software Engineering | 1 Comment

Looking for bugs (in several wrong places)

I recently went on a bug-hunt in a huge system that I knew next to nothing about. The reason I went on this bug-hunt was because, although I didn’t know the system itself, I knew what the system was supposed to do, and I can read and write all the programming languages involved in developing the system (C++, C and VHDL). I’m also very familiar with the protocol of which the implementation was buggy, so not knowing the system was a minor inconvenience.

These are some notes I took during the bug-hunt, some of which intentionally kept vague so as to protect the guilty.

Continue reading

Posted in Anecdotes, Software Development, Software Engineering, Software Testing | Tagged | Comments Off

Re: E-mail

The Globe&Mail dedicated half a page of the Report on Business section to managing your inbox today. People who work with me know that

  1. if you want to get ahold of me quickly, E-mail is not the way to go
  2. if you want a thought-out, thorough response, E-mail is the way to go

Continue reading

Posted in Opinions | Comments Off

ICS Security: Current and Future Focus

The flurry of DNP3-related vulnerabilities reported to ICS-CERT as part of Automatak’s project Robus seems to have subsided a bit, so it may be time to take a look at where we are regarding ICS security, and where we might be going next.

Of course, I’ll only look at communications protocol security in this context: low-tech attacks on the grid1 is outside the scope of this article. In stead, I will take a look at two questions: why the focus on DNP3, and what else could they, and should they, be looking at.

Continue reading

  1. e.g. letting two helium-filled balloons up with a wire between them, under a high-voltage power line, in order to cause a short between the phases
    Balloon hack illustration

    Balloon hack illustration — don’t do this!

    []
Posted in Industrial Automation, Smart Grid | Tagged , , | 6 Comments

Is Open Source software security falling apart?

There have been a number of well-publicized security flaws in open source software lately — the most well-publicized of course being the OpenSSL Heartbleed bug1.

Then there’s the demise of Truecrypt, recent bugs in GnuTLS and recent bugs in the Linux kernel.

So, is there a systemic problem with Open Source software? Does proprietary software have the same problem?

Continue reading

  1. OpenSSL is very widely used, which makes its effect on the Internet enormous, and the effect of bugs in the protocol implementation huge. That explains why such bugs are so well-publicized. Another factor in the publicity is the name of the bug (which was very well-found). []
Posted in Opinions, Software Development, Software Testing | Comments Off