shrughes

Check out http://noplaintext.com/. It promises military-grade encryption, in the browser.

Here’s a fun game to play. Before visiting, try to guess what mistakes they made.

Then visit the site, and when you read exactly what they do, try to guess what mistakes they made.

Then look at the code and see what mistakes they made.

Then see what you missed (and what I missed).

So far:
- The encryption key is generated with 47.6 bits of entropy.
- It’s generated using Math.random().
- There is no message authentication. The server can flip individual bits within the message.
- Obviously we have to trust noplaintext.com to send us an uncompromised web page.
- It links to google-analytics, so we also have to trust the Google analytics people.
- It links directly to https://crypto-js.googlecode.com/files/2.5.3-crypto-sha1-hma…, so we also have to trust the crypto-js maintainer, and the googlecode.com people.
- The whole system depends on being able to share the URL securely. But if you can do that, you could have just sent the message securely over that channel.

Programming music is annoying. The question of how to combine ideas of notes and instruments and waveforms into a song is probably more interesting than the art of concatenating strings into an HTML document. At first I thought I’d make things by combining arrays of samples using some array-of-samples-combiners and objects with this interface:

struct Music {
    // dumps [beg, end) of our sample region to out.
    virtual void Dump(vector<pair<int16_t, int16_t> >& out,
                      int32_t beg, int32_t end) = 0;
    // the length of this musical passage, in 1/44100ths of a second.
    virtual int32_t Length() = 0;
};

The problem with that is you can’t just tweak the shape of some sound without e.g. knowing how it’s normalized and such. Also it’s not the right toolkit for playing a note out loud.

Also it’s stereo. Do we want to support mono tracks?

So now I’m going with having some primitive sounds that have amplitude 1.0, frequency 1.0, and manipulators that can screw around with them, and then things can parameterize them into notes somehow. More details will be present within the next 13 hours.

The worst thing is when you get C++ constructors that look like this:

blah::blah(int block_id, size_t size, buffer_t *buf)
    : block_id(block_id), size(size), buf(buf) { }

This works fine — the buf variable gets initialized with the function parameter — but here’s what doesn’t work.

blah::blah(int block_id, size_t size, buffer_t *buff)
    : block_id(block_id), size(size), buf(buf) { }

Now buf or buff is misspelled, and we’re trying to implement buf with itself! Sure, Valgrind will catch this error, but still.

If you don’t end your member variable names with underscores, then end your parameter names with them.

Thank you.

P.S. Did you know that clock_gettime(CLOCK_MONOTONIC, ___) doesn’t perform a system call? Neither does time(NULL), at least on up-to-date Linux. Anyway, I didn’t know this. CLOCK_MONOTONIC is still absurdly slow. It takes 1300 nanoseconds the first time you call it, and a few hundred after that. Using the rdtsc instruction in an inline function gets you to 13 ns between calls. This is on a 2.3 GHz system.

(The timings of CLOCK_MONOTONIC were measured by calling it twice in a row, and then by calling it twice in a row again. Similarly for rdtsc. So if anything, the first call to CLOCK_MONOTONIC may be slower than I reported, if there is any cost prior to the rdtsc instruction.)

One bad programming technique is that of asynchronous code designed
such that it always calls the callback.  That is, imagine a method as
follows:

    struct io_cb {
        virtual void done(void *buf) = 0;
    };

    void read(off64_t offset, off64_t len, io_cb *cb) {

        // If the buf is immediately available, calls cb->done(buf)
	// and then returns, if not, returns and later calls cb when
	// the buf becomes available.

    }

The problem with this sort of API is that if your bufs are all
immediately available, you can get unbounded mutual recursion.

Instead, here's a better API.

    struct tramp {
        virtual tramp *continue();
	void loopout() {
            tramp *t = this;
	    while ((t = t->continue())) { }
	}
    };

    struct io_cb : public tramp {
        void *buf;
    };

    struct nop : public tramp {
        void continue() {
            delete this;
            return NULL;
        }
    };

    tramp *read(off64_t offset, off64_t len, io_cb *cb) {
        if (/* the buffer is immediately available */) {
            cb->buf = /* the buffer */;
	    return cb;
	} else {
	    /* take ownership of cb and save it for later;
	       start the asynchronous operation. */
	    return new nop();
	}
    }

Then, to call it:

    read(off, 4096, my_callback)->loopout();

Use the right kind of smart pointers to make this better.  Then you
can also add debug variables and assertions in the destructor to make
sure the return value of a tramp never gets ignored.

Another way to do this is to just return a bool or a value that can be
NULL.

    void *read(off64_t offset, off64_t len, io_cb *cb) {
        if (/* the buffer is immediately available */) {
	    return /* the buffer */;
        } else {
            /* take ownership of cb and save it for later,
	       start the asynchronous operation. */
	    return NULL;
	}
    }

Then calling that looks like this:

    void *buf = read(off, 4096, my_callback);
    if (buf)
        my_callback->done(buf);

That gets annoying and makes you want to do the first technique
mentioned, which is bad.