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

“A camel is a horse designed by a committee”

I don’t usually use this blog to vent frustration, but I’ve been reading standards lately…

There are four versions of the horse:

  • Pony. Horses as the Good Lord intended them. Strong and sturdy, yet soft and cuddly; obedient yet intelligent; and I’m told they’re rather tasty too!
  • Horse. All the qualities of the pony, without the esthetics.
  • Donkey. The beta version of the pony: strong and sturdy, but none of the frills and quite a few bugs in the programming. Also: they don’t taste nearly as good (or so I’m told).
  • Ass. What the beta version became when the PMO took over.
  • Cow. A forked-off project from the (then open-source) Horse project that went for taste, combined with a bigger ass for the workload (in the form of an ox — you didn’t think I misspelled ass, did you?)
  • Dromedary. When some of the committee members got tired of trying to reach a consensus, they took what they had and ran with it — even if it’s running was more than a bit awkward.
  • Camel. None of the looks. Some of the features. Some features you didn’t think a horse should have. Some you didn’t think a horse could have. More of the smell. Much, much more.

When you count, that doesn’t add up to four, does it?

That’s what design by committee is all about!

Continue reading

Posted in Software Engineering | Comments Off