newtype in C, a touch of strong typing using compound literals.

The ISO C 99 standard is a great thing. In addition to desperately needed things like a dedicated bool type and codifying a lot of universally implemented extensions to the language, it added some more subtle things such as compound literals. A compound literal allows you to use a C struct or union as an initialized literal value. This makes declared types more on par with built in ones, such as numbers, characters, and strings. Here I will present just about the simplest but quite useful application of this.

Many modern languages such as Haskell have a concept of a type alias. It is called a newtype in Haskell and I will borrow that terminology here. A newtype is a type that is fully equivalent at run-time and in generated code to an existing type, but nevertheless is distinct to the type system at compile time. They are quite useful in enforcing abstraction of APIs and catching a wide variety of bugs without incurring any run-time penalty. In fact, depending on the compiler, they may actually help optimization. Imagine you represent open files as an index into a table, much as the unix API does, naturally you would represent it by an int. You may have something like this, declaring fd_t as a handy synonym to show when you are working with file descriptors.

typedef int fd_t;
/* write an int out to a file */
void put_int(fd_t fd, int c);

Now, what happens if someone forgets the order of the arguments to put_int? since fd_t is a synonym for int, the compiler has no idea you did anything wrong and happily writes garbage to a random file. Not what we wanted at all. If fd_t were a newtype rather than a typedef synonym then the program would be rejected, because fd_t and int would be distinct types.

This brings us to the following bit of code you can place in a header file newtype.h. Using compound literals, it allows the declaration of newtypes that can be used almost anywhere you can use built in types.

#ifndef NEWTYPE_H
#define NEWTYPE_H
/* this can be used for type safety, to avoid accidental casting of values from one type to another and
 * allowing alias analysis by the compiler to distinguish otherwise identical types
 * NEWTYPE(new_type,old_type); declares new_type to be an alias for the already exsiting old_type
 * TO_NT(new_type,val)  converts a value to its newtype representation
 * FROM_NT(new_val)  opens up a newtyped value to get at its internal representation
#define NEWTYPE(nty,oty) typedef struct { oty v; } nty
#define FROM_NT(ntv)       ((ntv).v)
#define TO_NT(nty,val)     ((nty){ .v = (val) })

Now we can modify the above example, instead of

typedef int fd_t;

we use


Another example would be the traditional lseek routine that comes with C. it is generally declared as something like

#define SEEK_SET 0
#define SEEK_CUR 1
#define SEEK_END 2
long lseek(int fd,long offset, int whence);

Now, whence is supposed to be one of the SEEK_* defined terms, and fd is supposed to be an open file descriptor, and offset is supposed to be an offset into the file. however, to the compiler on many architectures all the argument types are indistinguishable. this means that if you mix up any of them, the compiler will happliy go along. in addition, you can pass bogus values in for ‘whence’ like 5 or 6, and nothing will complain. using newtypes, you might declare the API like so.

#define SEEK_SET TO_NT(whence_t,0)
#define SEEK_CUR TO_NT(whence_t,1)
#define SEEK_END TO_NT(whence_t,2)
long lseek(fd_t fd,long offset, whence_t whence);

Now, not only are you protected from mixing up any of the arguments, you are also protected from bogus values being passed into the whence argument meaning you can elide the run-time check for valid values since the compiler will check it for you.

Although this is just the simplest use of compound literals, it is already proving to be quite useful. When combined with other C99 features such as variable length arrarys you can do clever things like non-conservative garbage collection in a clean way, or just make your code that much easier to read by not having to declare temporary structures everywhere.

On Biometrics and Passwords

It seems that whenever the topic of biometrics comes up there are some that can’t stop worrying about what will happen if someone gets ahold of your biometric data. After all, how hard is it to lift a fingerprint off a glass at a pub? Will using fingerprints for authentication mean you have to wear gloves everywhere or be subject to identity theft or will you have to burn off your prints and get new ones if someone compromises your fingerprint? Well, The answers are no. The reason for the confusion probably stems from thinking of biometrics as passwords, secret things that only you have. However, this is not the case at all.  The security of biometrics comes from the fact there is only one human that matches the profile, not the secrecy of the profile itself.

A fingerprint cannot be compromised. A biometric identifier is not like a password. it is not meant to be secret. Think of your fingerprint as… well… like a public key cryptographic fingerprint really. Your public key fingerprint isn’t secret. in fact, you generally want to distribute it as far and wide as possible. What makes it useful is that there is a corresponding private key that only you have that can be matched to said public key. A physical fingerprint is similar, everyone knows your fingerprint but there is only one warm human body that is associated with it. Present the warm human body (your own) that matches the fingerprint on file and you gain access. So we have the analogy that a public key fingerprint is to a private key as a physical fingerprint is to a warm human body with said fingerprint.

This of course means that biometrics are only good for ‘online’ verification, meaning there is a trusted path between your body and whomever you are identifying with. this can be anything from a physically secure ATM, a security guard that applys the test, or whatever is appropriate for the application. The security of biometrics comes not from the secrecy of the fingerprint, but the security of the path from the human being biometrically tested to the verifyer. Hence, you cannot ‘compromise a fingerprint’. You can however compromise a specific biometric system. If you find you can lift and transfer fingerprints easily with a gummy bear for a specific reader, you have broken that particular reader, but you don’t need to burn off your fingerprints and get new ones (like you change passwords when one has been compromised). you simply stop trusting anything that uses said broken reader.

PS. does anyone else enjoy the irony of using an abstract mathematical concept to explain a straightforward real world transaction? 🙂

ShapeLock and Hot Glue = Rapid Funny Looking Prototypes

While waiting for the parts to my very own reprap machine, I figured I would experiment a little with some possible head designs. One I am particularly interested in is something like a ‘pick and place’ machine that can manipulate objects in 3 dimensions. My simple design involves a drinking straw, a couple $3 hobby servos, a bunch of hand molded shapelock, and a few hot glue burns.

Here is the final result:


The basic idea is the bottom servo (bottom is to the left) can bend the straw left and right, and the other servo can rotate the straw in place. the bend in the straw acts as a universal joint so the object held can be rotated somewhat arbitrarily in 3 dimensions.


A simple linkage connects the top servo to the straw. I attempted a couple different things, starting with a pully system, then a gear system. neither worked out too well. The linkage turned out to be quite simple and robust.


Here it is with the attached fan I attempted to use as a vaccum pump. It did not turn out too well, the fan was scavanged from an old CPU and was never meant to be used like this, so I will need an actual vaccum pump at some point.

Everything was controlled for testing with a Wii nunchuck and an arduino microcontroller with custom code. Here is a video of it in action:

You need to a flashplayer enabled browser to view this YouTube video

So, some stuff I learned

  • ShapeLock is wonderful stuff. I was able to form and reform the head a few times, even fairly large changes like making room for a gear involved reheating a part of the project and shaping it by hand. And I can just melt it down again and reuse it for my next prototype.
  • The linkage is the way to go. I struggled a long time with gears and pullys. I imagine that if I were precision machining things and could get gears/pullys in the exact right size, things would have been different. But when it comes to the fuzzy world of hand-squished shapelock, the more forgiving linkage worked out great.
  • I am gonna stock up on these tiny and cheap servos. They have a very interesting and useful bug. if you try to overextend them, they go into continuously rotating mode with no modification! So you can have the same servo work as a continously rotating one at some points, but also have precise precisioning at others.
  • The Wii nunchuck is a great little thing. it took a few dozen lines of arduino code to interface with it and I got a joystick, 3 buttons, and a 3 axis accelerometer.