Another useless C99 tidbit
From page 18 of the C99 standard:
All occurrences in a source file of the following sequences of three characters (called trigraph sequences) are replaced with the corresponding single character.
??= # ??( [ ??/ \ ??) ] ??' ^ ??< { ??! | ??> } ??- ~No other trigraph sequences exist. Each ? that does not begin one of the trigraphs listed above is not changed.
Ok, so take the following C program:
??=include <stdio.h> int main(int argc, char *argv??(??)) ??< printf("hello world\n"); ??>
And compile it with the -trigraphs switch to gcc:
dirac src $ gcc -trigraphs -o trigraphs trigraphs.c dirac src $ ./trigraphs hello world
Combined with this you could seriously obfuscate your C code.
Hidden Gems in C99 (1)
After some late night reading of the C99 spec, I've found quite a few hidden gems. I'm going to start posting some of these. Since it's late, I'll just post a teaser.
On page 64 of the C99 standard it says:
In all aspects of the language, the six tokens
<: :> <% %> %: %:%:behave,respectively,the same as the six tokens
[ ] { } # ##except for their spelling.
Really? Then let's try this program:
%:include <stdio .h> int main(int argc, char *argv<::>) <% printf("hello world\n"); %>
Compile it an run it:
dirac src $ gcc main.c dirac src $ ./a.out hello world
Whaddaya know... I know, I know... useless. Wait for the next post then.
Cold Boot Attacks Against Disk Encryption
Bruce Schneier linked to an interesting article on techniques for reading the DRAM contents of a machine after it has been powered off.
We show that disk encryption, the standard approach to protecting sensitive data on laptops, can be defeated by relatively simple methods. We demonstrate our methods by using them to defeat three popular disk encryption products: BitLocker, which comes with Windows Vista; FileVault, which comes with MacOS X; and dm-crypt, which is used with Linux.
[...]
The root of the problem lies in an unexpected property of today’s DRAM memories. DRAMs are the main memory chips used to store data while the system is running. Virtually everybody, including experts, will tell you that DRAM contents are lost when you turn off the power. But this isn’t so. Our research shows that data in DRAM actually fades out gradually over a period of seconds to minutes, enabling an attacker to read the full contents of memory by cutting power and then rebooting into a malicious operating system.
Interestingly, if you cool the DRAM chips, for example by spraying inverted cans of “canned air” dusting spray on them, the chips will retain their contents for much longer. At these temperatures (around -50 °C) you can remove the chips from the computer and let them sit on the table for ten minutes or more, without appreciable loss of data. Cool the chips in liquid nitrogen (-196 °C) and they hold their state for hours at least, without any power. Just put the chips back into a machine and you can read out their contents.
This is deadly for disk encryption products because they rely on keeping master decryption keys in DRAM. This was thought to be safe because the operating system would keep any malicious programs from accessing the keys in memory, and there was no way to get rid of the operating system without cutting power to the machine, which “everybody knew” would cause the keys to be erased.
Our results show that an attacker can cut power to the computer, then power it back up and boot a malicious operating system (from, say, a thumb drive) that copies the contents of memory. Having done that, the attacker can search through the captured memory contents, find any crypto keys that might be there, and use them to start decrypting hard disk contents. We show very effective methods for finding and extracting keys from memory, even if the contents of memory have faded somewhat (i.e., even if some bits of memory were flipped during the power-off interval). If the attacker is worried that memory will fade too quickly, he can chill the DRAM chips before cutting power.
There seems to be no easy fix for these problems. Fundamentally, disk encryption programs now have nowhere safe to store their keys. Today’s Trusted Computing hardware does not seem to help; for example, we can defeat BitLocker despite its use of a Trusted Platform Module.
Notice that this attack is particularly dangerous because it can be trivially automated. All you need is a USB drive or CD with the malicious operating system already set up. If you have access to a system (e.g. a laptop), all you need to do is shut it down and boot it up from your malicious OS and you have a copy of the DRAM and thus the encryption keys.
A little known fact from Apple hardware is that it supports setting a password in the Open Firmware which will prevent the machine from booting from any device other than the built-in hard drive. I highly recommend using this option. I believe it could help in defeating even this new sophisticated attack.
Unless the attacker is careful to freeze the DRAM and pull it out of the laptop and transfer it to another machine to read it from there, the contents will be erased while he figures out that the machine can't boot from a different drive. It's a simple countermeasure that is available today. It won't work in all cases, but it certainly will defeat a fair number of them.
Tête de Moine and… Challah?
This weekend I was surprised by an invite from a friend to have dinner at his house. I was even more surprised when he gifted me a Girolle and a Tête de Moine. Wow! What a present!
Unfortunately, I couldn't find any Zopf to eat my cheese with. If anyone knows of a Swiss bakery in the bay area, I'd like to know. At any rate, the bread you see in the picture is actually a Challah, which doesn't have milk and has honey, so it's not quite the same flavor. However, it was ok for having the Tête de Moine.
I've also found Tête de Moine at iGourmet, so I'll be able to get some more once I finish this one. Is there a place in the bay area where they sell Tête de Moine?
Beautiful Emacs (Windows Edition)
After fixing the font on my Carbon Emacs on Mac OS X, I'm spoiled with good fonts. Today I had to work on Windows and naturally, the only way to make Windows liveable is to work inside Emacs.
This is what a default installation of EmacsW32 looks like.
Oh horror! You guys are kidding, right? Courier? Seriously?
Naturally, my first inclination was to use Inconsolata again. Just like in Mac OS X. However, this is what Inconsolata looks like.
WTF? What's with all the blurred text? Well, it turns out that anti-aliasing and text rasterization differ significantly between Mac OS X and Windows. Oh well. Scratch that plan.
Then I remembered that Incosolata is actually based on Consolas, which is a font Microsoft created specifically for programming.
I downloaded and installed Consolas, and voilà! Beautiful Emacs once again.
Now it was just a matter of figuring out what the font was called. I had changed the font by clicking on the Emacs frame and pressing the shift key. In order to see what that does, I ran the describe-key function by typing C-h k, then clicking on the frame while holding the shift key. That told me the function that is called is mouse-set-font and it's defined in c:/Program Files/Emacs/emacs/lisp/term/w32-win.elc. You can click on the file link and Emacs will take you to the function definition.
(defun mouse-set-font (&rest fonts) "Select an Emacs font from a list of known good fonts and fontsets. If `w32-use-w32-font-dialog' is non-nil (the default), use the Windows font dialog to display the list of possible fonts. Otherwise use a pop-up menu (like Emacs does on other platforms) initialized with the fonts in `w32-fixed-font-alist'. If `w32-list-proportional-fonts' is non-nil, add proportional fonts to the list in the font selection dialog (the fonts listed by the pop-up menu are unaffected by `w32-list-proportional-fonts')." (interactive (if w32-use-w32-font-dialog (let ((chosen-font (w32-select-font (selected-frame) w32-list-proportional-fonts))) (and chosen-font (list chosen-font))) (x-popup-menu last-nonmenu-event ;; Append list of fontsets currently defined. ;; Conditional on new-fontset so bootstrapping works on non-GUI compiles (if (fboundp 'new-fontset) (append w32-fixed-font-alist (list (generate-fontset-menu))))))) (if fonts (let (font) (while fonts (condition-case nil (progn (setq font (car fonts)) (set-default-font font) (setq fonts nil)) (error (setq fonts (cdr fonts))))) (if (null font) (error "Font not found")))))
Now, I don't know what all of that does, but it seems like (set-default-font font) is the one function that actually sets the font. In order to figure out what the font is called, I copied all of the function to the good old *scratch* buffer, and added a call to (message font) right after the call to (set-default-font font). Then I redefined the function by typing C-x C-e at the end of it. After shift clicking on the frame again and selecting the Consolas font I had all the information I needed.
Now it was just a matter of putting the following snippet in my .emacs file:
(set-default-font "-outline-Consolas-normal-r-normal-normal-14-97-96-96-c-*-iso8859-1")
Ahh... I feel so much better now... now what was I doing in Windows again?
Lazy-loading emacs functionality
Quick, how big is your .emacs file? How long does it take emacs to load? A few days ago I found that my .emacs file had slowly grown to the point where it was taking emacs a significant amount of time to load. Something needed to be done.
A quick glance at the file told me I was loading a lot of modules that I seldom use. For instance, I occasionally write some code in Common Lisp or Haskell, so naturally I was loading slime and the haskell environment. I commented those out.
However, after commenting them out, I quickly realized that not loading them was problematic. When I wanted to use them, I had to open my .emacs file, uncomment the relevant portion, and M-x eval-region the code.
Then it occurred to me that I had a clear entry point for some of these modules. When I write Common Lisp, I usually start by loading SLIME's REPL by running M-x slime. I came up with the following code:
(defun slime () (interactive) (add-to-list 'load-path "~/emacs/slime") (setq inferior-lisp-program "/usr/local/bin/sbcl") (require 'slime) (slime-setup) (slime))
Which basically sets up my slime environment and then loads slime. Note that the slime function itself is redefined as part of the evaluation of (require 'slime), so although this looks like a recursive call, it's not.
I've used this trick in several other cases and I think it's kind of neat. It helps me keep Emacs loading fast, but I still have all the bells and whistles available.
Leave a door open (for Peace)
Today is John Lennon's death anniversary. He was shot to death on December 8th, 1980. I always commemorate this day by listening to John Lennon's music, smoking unfiltered Gitanes, playing guitar, and letting my hair grow long... for a day... ok, not really, but I do try to listen to Imagine, at least once.
At any rate, there is a website now to commemorate John. It has a letter from Yoko Ono and a video from John Lennon.
The goal of an artist is to elicit some kind of emotion from the audience through his art. You cannot see the video and feel nothing. I left it running in the background while doing other things as I've seen Lennon interviews thousands of times and can usually remember how they go, but the imagery at the end, after John stops talking, pulled my eyes and engaged me like nothing has for a long while. I literally couldn't stop watching.
At any rate, here's to you John Lennon. You were the Walrus.
Vive la différence
One of the more useful programs in the developer's toolkit is diff. This little utility compares two files and gives you just the differences (what changed) between them. Evey version control system in the world is ultimately based on diffs.
One way I commonly use it, is to see what I've changed in a file or a set of files. Let me clarify. I put everything in version control. Even tiny little programs that I'm tempted to throw away are in version control. Being able to use diff between my modified file and the previous version is a major reason for doing so.
Now, if I told you to quit your editor and run diff in a terminal, I wouldn't be surprised if you decided to beat me with a clue stick. You should NEVER leave your editor. If you do, you don't know how to use your editor, or your editor is not powerful enough. If your problem is the latter, you should switch to Emacs right now. Otherwise, keep reading, I can help you.
Depending on what version control system you use, you should modify the commands given below. I use BitKeeper (well, duh!), so all my examples will use that one.
To start with, stick this in your .emacs:
(defun bk-diffs () "Get diffs between current edited buffer and checked in revision" (interactive) (let* ((filename (buffer-file-name (current-buffer))) (newbuf (get-buffer-create (format "%s diffs" (if filename (buffer-name) default-directory))))) (set-buffer newbuf) (if buffer-read-only (toggle-read-only)) (erase-buffer) (insert (shell-command-to-string (if filename (format "bk diffs -uph %s" filename) "bk -r diffs -uph"))) (switch-to-buffer-other-window newbuf) (diff-mode) (beginning-of-buffer) (diff-hunk-next) (toggle-read-only) newbuf))
Now, whenever you are in a file and want to modify it, all you need to do is run the command bk-diffs and you'll get something like this:
Cool, eh?
The command is also context sensitive, so if you run it from a buffer where you're not editing a file, e.g. a dired buffer or a shell buffer, it will run a recursive diff and give you diffs for all the files. I use this all the time when I go back to repositories I haven't touched in a while. It's my "what the hell was I doing?" command. The output looks something like this:
That's not all. I have more tricks for you. First of all, navigation:
| n or M-n | Move to the next hunk |
| p or M-p | Move to the previous hunk |
| M-N | Move to the next file |
| M-P | Move to the previous file |
If you are an old school hacker and would rather see context diffs than unified diffs, you can hit C-c C-d while in the diffs buffer. To go back to unified diffs, hit C-c C-u.
There are also key strokes for going back to the source file from the diff buffer. Pressing Enter or M-o or
Ok, that is useful, but I see you're not blown away. The truth is, I saved the best part for last. Once you're walking the diffs one by one, you can also press C-c C-a to either apply, or revert a hunk! How cool is that eh?
This last feature is something I use all the time to clean up a file before checking it in. E.g. I sometimes have a bunch of debug code or comments to myself that need to be removed before checking the file in. Rather than review the file by hand, I can go through the diffs and use the quick navigation that emacs provides for doing the clean up.
Finally, if you are a CVS user (I'm sorry, really. You should switch to something else), you can probably still use it inside vc-mode, hit C-x v = to get the diffs and try the keystrokes I mentioned.
Beautiful Emacs
When you spend all day looking at code, it's important to select a good editor font. Obviously, the font needs to be monospaced or the alignment will be all wrong. Well, there are only a handful of monospaced fonts worth looking at (and Courier is not one of them).
Take a look at the following image. Click on it, and pick your favorite of the four fonts.
These are the fonts in the image, clockwise from the top left corner: Bitstream Vera Sans Mono, Andale Mono, Monaco, and Inconsolata.
Bitstream Vera Sans Mono is my second favorite. It's the font I use on my web browser. However, for editing code, I find it a bit too heavy. This probably has more to do with my color scheme than the font per se, so your millage might vary.
Andale Mono is very readable, but I find the spacing all wrong and somewhat distracting. Look at the word "String", the letters seem too far apart.
Inconsolata is my personal favorite. You need to crank up the font size because it seems to be a smaller font than the rest. I thought that point sizes were supposed to be standard, but apparently I was wrong.
Monaco is the default in Mac OS X, but it looks kind of silly. I used to use whatever was the default, so I've used this font quite a while. I never did mind it, but once I made the switch to Inconsolata, I can't stand it anymore.
If you want to play with different fonts in Carbon Emacs, you can enable mac keys by running the (mac-key-mode) function, and then pressing ⌘T, which will open a standard font dialog.
However, if you want to use Inconsolata as your default font, put this in your .emacs
(require 'carbon-font) (fixed-width-set-default-fontset "-apple-inconsolata-medium-r-normal--14-*-*-*-*-*-iso10646-1")
It took me a while to figure out how to change the font on Carbon Emacs, so I hope that even if you don't choose Inconsolata as your preferred font, this information might prove useful.