Why I’m suspicious of car insurance dongles

The Lone C++ Coder's Blog from The Lone C++ Coder's Blog

Some security researchers from UCSD showed a proof of concept exploit via one of the dongles that appears to be also used by car insurance companies to monitor your driving “to give you discounts for good driving”. I’m not really a fully paid up subscriber of the tin foil hat brigade but stuff like this makes me glad that I’m still opting for the old-fashioned way of paying for car insurance.

TLS issues with Emacs and Git for Windows

The Lone C++ Coder's Blog from The Lone C++ Coder's Blog

I’ve recently blogged about adding TLS support to Emacs 24.5 on Windows and improving git performance on Windows by installing an alternative git command line client. The reason I ended up investigating how to add SSL and TLS support to Emacs is that when I originally upgraded from the official git Windows client to the Git for Windows build, I ended up with non-working TLS support in Emacs. The TLS issues only occur if you tell the git installer to add git and all supporting Unix utilities to the path, which is not the default setting for a git installation on Windows.

Improve git performance on Windows without patching your git install

The Lone C++ Coder's Blog from The Lone C++ Coder's Blog

I’ve blogged about improving the performance of Git on Windows in the past and rightly labelled the suggested solution as a bad hack because it requires you to manually replace binaries that are part of the installation. For people who tend to use DVCSs from the command line, manually replacing binaries is unlikely to be a big deal but it’s clunky and should really be a wakeup call for some people to include a newer base system.

Adding TLS support to Emacs 24.5 on Windows

The Lone C++ Coder's Blog from The Lone C++ Coder's Blog

The Windows build of Emacs 24.5 doesn’t ship with SSL and TLS support out of the box. Normally that’s not that much of a problem until you are trying to access marmalade-repo or have org2blog talk to your own blog via SSL/TLS. Adding SSL and TLS support to the Windows builds of Emacs is easy. SSL/TLS support in the official Emacs build for Windows isn’t enabled because it doesn’t ship with the necessary support libraries, but you can get pre-built binaries from the ezwinports project on Sourceforge.

A Game of Tag

Phil Nash from level of indirection

One of the tent-pole features of Catch is the ability to write test names as free-form strings. When you run a Catch executable from the command line you can specify a test case by name, to run just that one:

./MyTestExe "a very nice test case"

or you can use wildcards to run a group of test cases (or just one with less typing):

./MyTestExe "*very nice*"

If you want to use wildcards but you're not sure what they'll match you can combine this with the listing option, -l, to see which test cases match the pattern:

./MyTestExe "*very nice*" -l
Matching test cases:
  a very nice test case
  a not very nice test case
2 matching test cases

This is already quite a powerful way to group test cases into ad-hoc "suites". However we don't want to twist our test names into artificial schemes for this purposes (although, early on, that's exactly what I proposed). Instead Catch allows you to add "tags" to test cases.

TEST_CASE( "a very nice test case", "[nice][good]" ) { /* ... */ }
TEST_CASE( "a not very nice test case", "[nice][bad]" ) { /* ... */ }

Now we can run all tests with a certain tag:

./MyTestExe [good]

or combination of tags:

./MyTestExe [nice][good]

also with exclusions:

./MyTestExe [nice]~[bad]

unions are supported with ,:

./MyTestExe [nice],[pleasant]

Very powerful! And this functionality has been around for a while.

More recent, and less well known (mostly because they weren't documented until recently) are a set of "special tags": Instruction Tags, Hiding Tags, Tag Aliases and some automatically generated tags.

Let's see what they're all about.

Instruction Tags

In general all tags that start with a symbol are reserved by Catch (or, put another way, user defined tag names must start with an alpha-numeric character). This allows a nice rich range of namespaces for special tags. Tags that start with the ! character are Instruction tags. They inform Catch something about the test case that they apply to. At time of writing the following are defined:

  • [!hide] This "hides" the test from the default run (i.e. if you run the test executable without specifying any names or tags). This feature was originally introduced with the [hide] tag (note, no: !) - and is still supported, though deprecated. There is also a shortcut form, [.] which we'll revisit in a moment.
  • [!throws] This tells Catch that an exception may be thrown in the course of executing the test - even if it is caught and dealt with. If you've ever tried to track down a rogue exception in your debugger - and so have set the debugger to break on exceptions as they're thrown - you'll know how frustrating all the false positives coming from such tests are! So Catch provides a way to suppress exceptions it is expecting - through the -e or --nothrow options on the command line. This already skips over REQUIRE_THROWS... or CHECK_THROWS... assertions. The [!throws] tag covers you for cases where the exception is caught and handled in the code under test (or your test code).
  • [!shouldfail] This tells Catch that you're expecting this test to fail! Furthermore, if it does fail then it should treat that as a pass!
  • [!mayfail] Rather than explicitly inverting the pass/ fail logic as the previous tag does, this tag just says that the test may fail but that's ok (although it is still reported). It's also ok if it passes.

Hiding Tags

We already looked at [!hide] (and the deprecated [hide]) above, and mentioned that [.] was a shortcut for the same.

It turns that when one of these tags is used it is often combined with another tag that is used when you do want to run the test. The classic example is where you write integration tests in the same executable as unit tests. By default you don't want the integration tests to run as you want the shortest possible path to running just unit tests. So you hide them but also tag them [integration], or something similar (the word "integration" has no significance to Catch). So pairings like, [.][integration] or [.][performance] are frequently found together.

So, as a convenience, Catch now supports . as a tag prefix. The rest of the tag can be completely custom and works exactly like any other normal tag - except that the test is also hidden. Our examples would, thus, be written as [.integration] and [.performance]

One final point to mention about hiding tags is that, due to the way they have evolved through a number of forms (including the severely deprecated "./" name prefix) whichever form is used will not only hide the test, but any of the other forms will match it in a tag pattern. e.g. if you tag a test with [.] you can match it with [!hide].

Tag Aliases

As we saw earlier, tags can be combined in fairly complex ways. While this is powerful and flexible, it can be a bit awkward if you often want to use the same tag expression. Wouldn't it be nice if there was a way of writing the expression once then getting Catch to remember it for you - and associate it with an easier to remember name?

Well there is! You can associate any tag pattern with a name that you can use just like any normal tag - except that it must begin with the @ character.

You create a tag alias, in code, using the CATCH_REGISTER_TAG_ALIAS macro. E.g.

CATCH_REGISTER_TAG_ALIAS( "[@not nice]", "~[nice]~[!hide]" );

This registers a tag alias, [@not nice] which, when expanded will match all tests that are not tagged [nice] but also are not hidden. The second part is important because if you have any hidden tests then they will usually be included any time you use a not expression (~) because the rule is that tests are only hidden if no pattern is specified!

Also did you notice that we had a space in the tag name? Surprised? I never said that tags could not include spaces. Of course they can.

You can register as many aliases as you like and you can put them anywhere you like (as long as catch.hpp is #included). However I recommend keeping them all in your main source file (the one you #define CATCH_CONFIG_MAIN, or equivalent) - simply so you only have to look in one place for them.

Filenames As Tags

The newest special tag form is the result of automatically generating a set of tags. The tags all begin with the # character (I've resisted the urge to call them "hash tags"). The rest of the tag is generated from the name of the source file that the test is implemented in. The full path (as reported by __FILE__) is stripped of its directories and extension - so all tests in /Development/Tests/SquirrelTests.cpp would be tagged, [#SquirrelTests].

At time of writing this feature is only available on the develop branch on GitHub - and must be specifically enabled running with the --filenames-as-tags or -# command line options. It's possible that situation may change by the time it makes it onto master.

The Tag Line

So tags not only provide a rich grouping mechanism in Catch - they also allow you to control some aspects of how Catch runs and treats test cases. Some tags can be generated for you - and some tags can be expanded from simpler forms. We've covered here the complete set of special tags at the time of writing. If you're reading this in the future there may be more - I'll try and be better at keeping the docs up-to-date there. Also any stock price tips you might have from the future would be welcome too.

Interview: Fog Creek (Going Beyond Code to Become A Better Programmer)

Pete Goodliffe from Pete Goodliffe

I recently did a short interview with the guys at Fog Creek on the subject Becoming a Better Programmer. You can view it here.

It's a heroic editing effort! Between unreliable network connections and probably a 40 minute conversion they've heroically cut it down to ten minutes, and made me look rather like Max Headroom.

There's been lots of great feedback about this, so I'm glad it's inspiring people.

Did Bell Labs initially try to hide that C was based on BCPL?

olvemaudal from Geektalk

During research for my talk “History and Spirit of C and C++” (pdf, 11Mb) I realized that the reference manual Ken Thompson wrote for B in 1972 (pdf) was in parts a verbatim copy of the reference manual that Martin Richards wrote for BCPL in 1967 (pdf) (in particular look at page 6 in both documents or see slide 118-126 in my presentation). I guess that is fair as B is semantically basically the same language as BCPL. However, the odd thing is that in the more official reference manual for C dated 1974 (pdf), BCPL is not even mentioned at all.

“Good artists copy, great artists steal.” Perhaps this is just another kudos to Bell Labs, but I certainly found it interesting. It has to be said though that in all the interviews and later writings I have seen by members of Bell Labs, including Ritchie and Thompson, they are very open about BCPL being the main inspiration for B and C.