iodine 0.4.8 → 0.4.10

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: '08f011b1bc43d3c47d266fc0e2dab7379708e5de'
-  data.tar.gz: 1197234946e68f0515ce51d3f8858d948a0a77ef
+  metadata.gz: d8b8c9242c96289b1e60cbf4e0ffe72c343ba468
+  data.tar.gz: 9334e2369ab360f6559f233ebb1be190232b4439
 SHA512:
-  metadata.gz: aab2abfb29dea3efd0041c31abfbe93b3aac2fa21cf48fa48629263d58d6b636ff054d43acc33b3c7e24904a7240e42ef6e865218b1530bce530bf785adc4ef6
-  data.tar.gz: 4ed2825719fc986132ecbdb28d3c56c2bc23e752f1d67df794a92fc12c5f89c84c0b914ef7ad49bece19d2f01ac3790ddce73b858fe024a1fffaeab985eba6aa
+  metadata.gz: 8b1ce71015afc887cb0c748fe106774ea722884d58407b5d1a5836b1b6f0c60f05439afbc0508435aa89619d85e05723a2f802431c07bd659bc3663d603c9756
+  data.tar.gz: 8b38c0ecefb0b83a9bd5667a5f7403967e1e9fbbc984b9df990976a8071499bf9ec3f9b67cb65bfcc27a9bc728cc09e6b9e84cfbfe32c0a1e536f457df338e6e

data/.gitignore

@@ -12,5 +12,6 @@
 *.so
 
 .ruby-version
+.clang_complete
 
 .DS_Store

data/CHANGELOG.md

@@ -6,6 +6,26 @@ Please notice that this change log contains changes for upcoming releases as wel
 
 ## Changes:
 
+#### Change log v.0.4.10
+
+**Portability**: (`mac OS High Sierra`) iodine will load the Objective C library on macOS machines before starting up the server - this will prevent `fork` from crashing the server on macOS High Sierra, see [discussion here](https://github.com/puma/puma/issues/1421).
+
+**Fix**: (`facil.io`) fixes an error with the new Websocket parser (introduced in v. 0.4.9) that caused medium sized messages (127 Bytes - 64Kib) to be parsed incorrectly. Apologies. The test program I used seems to have validated messages using length comparison (instead of data comparison). Credit to Tom Lahti (@uidzip) for exposing the issue.
+
+#### Change log v.0.4.9
+
+**Change**: (`facil.io`) the internal Websocket parser was replaced with something easier to read, for maintainability reasons. Performance seems to be mostly unaffected (sometimes it's faster and sometimes it's slower, common case is slightly optimized).
+
+**Change**: (`facil.io`) iodine will compile facil.io with the `NO_CHILD_REAPER` flag, in order to workaround the Rails ExecJS gem that [assumes no child reaping is performed](https://github.com/rails/execjs/issues/68). This workaround is, hopefully, temporary. Credit to @jerryshen for exposing the issue.
+
+**Fix**: (`Iodine`) test for timer creation error in `run_after` and `run_every`.
+
+**Fix**: (`facil.io`) timer creation now correctly detects if the reactor was stopped, allowing the creation of new timers before the reactor's reactivation.
+
+**Fix**: (`facil.io`) timer timeout review is now correctly ignored, preventing the timer from being shut down prematurely.
+
+***
+
 #### Change log v.0.4.8
 
 **Change**: (`facil.io`) the internal HTTP parser was replaced with something easier to read, for maintainability reasons. Performance seems to be unaffected.
@@ -14,6 +34,8 @@ Please notice that this change log contains changes for upcoming releases as wel
 
 **Performance**: The `now` HTTP Date string is now cached for up to 2 seconds, improving performance for `Date`, `Last-Modified` and Iodine logging messages that relate to the current time. However, it's likely that Rack will write it's own date string, masking this feature.
 
+***
+
 #### Change log v.0.4.7
 
 **Update**: Now using `facil.io` edge (stripped down v.0.5.3).
@@ -26,12 +48,16 @@ Please notice that this change log contains changes for upcoming releases as wel
 
 **Fix**: (`defer`) a shutdown issue in `defer_perform_in_fork` was detected by @cdkrot and his fix was implemented.
 
+***
+
 #### Change log v.0.4.6
 
 **Update**: Now using `facil.io` v.0.5.2.
 
 **Fix**: (from `facil.io`) fix `SIGTERM` handling, make sure sibling processes exit when a sibling dies.
 
+***
+
 #### Change log v.0.4.5
 
 **Fix**: fix static file service for `X-Sendfile` as well as static error file fallback pages (404.html etc').

data/README.md

@@ -21,11 +21,11 @@ Iodine is an **evented** framework with a simple API that builds off the low lev
 
 * Iodine can handle **thousands of concurrent connections** (tested with more then 20K connections)!
 
-* Iodine supports only **Linux/Unix** based systems (i.e. OS X, Ubuntu, FreeBSD etc'), which are ideal for evented IO (while Windows and Solaris are better at IO *completion* events, which are totally different).
+* Iodine supports only **Linux/Unix** based systems (i.e. macOS, Ubuntu, FreeBSD etc'), which are ideal for evented IO (while Windows and Solaris are better at IO *completion* events, which are totally different).
 
 Iodine is a C extension for Ruby, developed and optimized for Ruby MRI 2.2.2 and up... it should support the whole Ruby 2.0 MRI family, but Rack requires Ruby 2.2.2, and so iodine matches this requirement.
 
-## Iodine::Rack == a fast and powerful HTTP + Websockets server with native Pub/Sub
+## Iodine::Rack == fast & powerful HTTP + Websockets server with native Pub/Sub
 
 Iodine includes a light and fast HTTP and Websocket server written in C that was written according to the [Rack interface specifications](http://www.rubydoc.info/github/rack/rack/master/file/SPEC) and the [Websocket draft extension](./SPEC-Websocket-Draft.md).
 
@@ -263,8 +263,10 @@ In pseudo-code, this might look like this
 QUEUE = Queue.new
 
 def server_cycle
-    QUEUE << get_next_32_socket_events # these events schedule the proper user code to run
-    QUEUE << [server]
+    if(QUEUE.empty?)
+      QUEUE << get_next_32_socket_events # these events schedule the proper user code to run
+    end
+    QUEUE << server_cycle
 end
 
 def run_server
@@ -276,9 +278,13 @@ end
 
 In pure Ruby (without using C extensions or Java), it's possible to do the same by using `select`... and although `select` has some issues, it works well for smaller concurrency levels.
 
-The server events are fairly fast and fragmented (longer code is fragmented across multiple events), so one thread is enough to run the server including it's static file service and everything... but single threaded mode should probably be avoided.
+The server events are fairly fast and fragmented (longer code is fragmented across multiple events), so one thread is enough to run the server including it's static file service and everything... 
+
+...but single threaded mode should probably be avoided.
+
+The thread pool is there to help slow user code.
 
-The thread pool is there to help slow user code. It's very common that the application's code will run slower and require external resources (i.e., databases, a pub/sub service, etc'). This slow code could "starve" the server (that is patiently waiting to run it's tasks on the same thread) - which is why a thread pool is often necessary.
+It's very common that the application's code will run slower and require external resources (i.e., databases, a custom pub/sub service, etc'). This slow code could "starve" the server, which is patiently waiting to run it's tasks on the same thread.
 
 The slower your application code, the more threads you will need to keep the server running smoothly.
 
@@ -290,7 +296,7 @@ Since the HTTP and Websocket parsers are written in C (with no RegExp), they're
 
 Also, iodine's core and parsers are running outside of Ruby's global lock, meaning that they enjoy true concurrency before entering the Ruby layer (your application) - this offers iodine a big advantage over other Ruby servers.
 
-Another assumption iodine makes is that it is behind a load balancer / proxy (which is the normal way Ruby applications are deployed) - this allows iodine to disregard header validity checks (we're not checking for invalid characters) and focus it's resources on other security and performance concerns.
+Another assumption iodine makes is that it is behind a load balancer / proxy (which is the normal way Ruby applications are deployed) - this allows iodine to disregard some header validity checks (we're not checking for invalid characters) and focus it's resources on other security and performance concerns.
 
 I recommend benchmarking the performance for yourself using `wrk` or `ab`:
 
@@ -325,7 +331,7 @@ $ RACK_ENV=production puma -p 3000 -t 16 -w 4
 
 When benchmarking with `wrk`, iodine performed significantly better, (~62K req/sec vs. ~44K req/sec) while keeping a lower memory foot print (~60Mb vs. ~111Mb).
 
-When benchmarking with `ab`, I got different results, where iodine still performed significantly better, (~72K req/sec vs. ~36K req/sec and ~61Mb vs. ~81.6Mb). I suspect the difference between the two benchmarks has to do with system calls to `write`, but I have no real proof.
+When benchmarking with `ab`, I got different results, where iodine still performed significantly better, (~72K req/sec vs. ~36K req/sec and ~61Mb vs. ~81.6Mb). I suspect the difference between the two benchmarks has to do with system calls to `write` and possible packet fragmentation, but I have no real proof.
 
 Remember to compare the memory footprint after running some requests - it's not just speed that C is helping with, it's also memory management and object pooling (i.e., iodine uses a buffer packet pool management).
 
@@ -345,9 +351,9 @@ If you have the development headers but still can't compile the iodine extension
 
 ## Mr. Sandman, write me a server
 
-Girls love flowers, or so my ex used to keep telling me... but I think code is the way to really show that something is hot!
+Iodine allows custom TCP/IP server authoring, for those cases where we need raw TCP/IP (UDP isn't supported just yet). 
 
-I mean, look at this short and sweet echo server - No HTTP, just use `telnet`... but it's so elegant I could cry:
+Here's a short and sweet echo server - No HTTP, just use `telnet`:
 
 ```ruby
 
@@ -427,12 +433,12 @@ Here's a few things you can use from this project and they seem to be handy to h
 
     I'm attaching it to one of iodine's library classes, just in-case someone adopts my code and decides the registry should be owned by the global Object class.
 
-* I was using a POSIX thread pool library ([`libasync.h`](https://github.com/boazsegev/facil.io/blob/master/lib/libasync.c)) until I realized how many issues Ruby has with non-Ruby threads... So now there's a Ruby-thread port for this library at ([`rb-libasync.h`](https://github.com/boazsegev/iodine/blob/master/ext/iodine/rb-libasync.h)).
+* I was using a POSIX thread pool library ([`defer.h`](https://github.com/boazsegev/facil.io/blob/master/lib/facil/core/defer.c)) until I realized how many issues Ruby has with non-Ruby threads... So now there's a Ruby-thread patch for this library at ([`rb-defer.c`](https://github.com/boazsegev/iodine/blob/master/ext/iodine/rb-defer.c)).
 
     Notice that all the new threads are free from the GVL - this allows true concurrency... but, you can't make Ruby API calls in that state.
 
     To perform Ruby API calls you need to re-enter the global lock (GVL), albeit temporarily, using `rb_thread_call_with_gvl` and `rv_protect` (gotta watch out from Ruby `longjmp` exceptions).
 
-* Since I needed to call Ruby methods while multi-threading and running outside the GVL, I wrote [`RubyCaller`](https://github.com/boazsegev/iodine/blob/0.2.0/ext/core/rb-call.h) which let's me call an object's method and wraps all the `rb_thread_call_with_gvl` and `rb_protect` details in a secret hidden place I never have to see again. It also keeps track of the thread's state, so if we're already within the GVL, we won't enter it "twice" (which will crash Ruby sporadically).
+* Since I needed to call Ruby methods while multi-threading and running outside the GVL, I wrote [`RubyCaller`](https://github.com/boazsegev/iodine/blob/0.2.0/ext/core/rb-call.h) which let's me call an object's method and wraps all the `rb_thread_call_with_gvl` and `rb_protect` details in a secret hidden place I never have to see again. It also keeps track of the thread's state, so if we're already within the GVL, we won't enter it "twice" (which could crash Ruby sporadically).
 
 These are nice code snippets that can be easily used in other extensions. They're easy enough to write, I guess, but I already did the legwork, so enjoy.

data/SPEC-Websocket-Draft.md

@@ -131,15 +131,19 @@ Internally, this extension also allows iodine to manage connection memory and re
 
 ## Iodine's Pub/Sub Extension to the Rack Websockets
 
-This extension separates the websocket Pub/Sub semantics from the Pub/Sub engine (i.e. Redis, MongoDB, etc') or the Server. If the Collection Extension is implemented, than this isn't necessarily a big step forward (the big step forward is what can be done with is).
+This extension separates the websocket Pub/Sub semantics from the Pub/Sub engine (i.e. Redis, MongoDB, etc'). This allows the Pub/Sub pattern to integrate with the Websocket API without the need for servers or applications to implement the Pub/Sub features.
 
-I don't personally believe this has a chance of being adopted by other server implementors, but it's a very powerful tool that Iodine supports.
+This allows Pub/Sub "engines" to seamlessly integrate with a server and offer Pub/Sub functionality for the specified environment, without the need for applications or servers to know anything about the Pub/Sub details or the environment.
+
+For example, Iodine includes three Pub/Sub engines `Iodine::PubSub::CLUSTER` (the default, for single machine multi-process pub/sub), `Iodine::PubSub::SINGLE_PROCESS` (a single process pub/sub) and `Iodine::PubSub::RedisEngine` (for horizontal scaling across machine boundaries, using Redis pub/sub)...
 
-Including these semantics, in the form of the described API, allows servers and Pub/Sub engines to be optimized in different ways without distracting the application (or framework implementor with environmental details.
+...but it would be easy enough to write a gem that will add another engine for MongoDB Pub/Sub and that engine would be server agnostic.
 
-For example, Iodine includes two default Pub/Sub engines `Iodine::PubSub::Engine::CLUSTER` (the default) and `Iodine::PubSub::Engine::SINGLE_PROCESS` that implement a localized Pub/Sub engine within a process cluster.
+If the Collection Extension is implemented, than this extension should be relatively easy to implement by the server.
+
+I don't personally believe this has a chance of being adopted by other server implementors, but it's a very powerful tool that Iodine supports.
 
- The Websocket module (i.e. `Iodine::Websocket`) includes the following singleton methods:
+The Websocket module (i.e. `Iodine::Websocket`) includes the following singleton methods:
 
  * `Iodine::Websocket.default_pubsub=` sets the default Pub/Sub engine.
 

data/bin/ws-echo

@@ -1,5 +1,8 @@
 #!/usr/bin/env ruby
 
+
+$VERBOSE = true
+
 Dir.chdir(File.expand_path(File.join('..', '..'), __FILE__))
 puts `rake clean`
 puts `rake compile`

data/examples/config.ru

@@ -28,7 +28,6 @@ module MyHTTPRouter
      # check if this is an upgrade request.
      if(env['upgrade.websocket?'.freeze])
        env['upgrade.websocket'.freeze] = WebsocketEcho
-       return [0, {}, []]
        return WS_RESPONSE
      end
      # simply return the RESPONSE object, no matter what request was received.

data/examples/echo.ru

@@ -12,6 +12,9 @@
 #
 #      ab -c 2000 -t 5 -n 1000000 -k http://127.0.0.1:3000/
 #      wrk -c2000 -d5 -t12 http://localhost:3000/
+#
+# Test websocket echo using the browser. For example:
+#      ws = new WebSocket("ws://localhost:3000"); ws.onmessage = function(e) {console.log("Got message!"); console.log(e.data);}; ws.onclose = function(e) {console.log("closed")}; ws.onopen = function(e) {ws.send("hi");};
 
 
 # A simple router - Checks for Websocket Upgrade and answers HTTP.
@@ -28,7 +31,6 @@ module MyHTTPRouter
      # check if this is an upgrade request.
      if(env['upgrade.websocket?'.freeze])
        env['upgrade.websocket'.freeze] = WebsocketEcho
-       return [0, {}, []]
        return WS_RESPONSE
      end
      # simply return the RESPONSE object, no matter what request was received.

data/examples/redis.ru

@@ -30,7 +30,6 @@ module MyHTTPRouter
      # check if this is an upgrade request.
      if(env['upgrade.websocket?'.freeze])
        env['upgrade.websocket'.freeze] = WS_RedisPubSub.new(env['PATH_INFO'] ? env['PATH_INFO'][1..-1] : "guest")
-       return [0, {}, []]
        return WS_RESPONSE
      end
      # simply return the RESPONSE object, no matter what request was received.

data/ext/iodine/base64.c

@@ -37,27 +37,6 @@ static unsigned base64_decodes[] = {
     0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,
     0,  0,  0,  0,  0,  0,  0,  0,  0};
 
-/**
-a union used for Base64 parsing
-*/
-union base64_parser_u {
-  struct {
-    unsigned tail : 2;
-    unsigned data : 6;
-  } byte1;
-  struct {
-    unsigned prev : 8;
-    unsigned tail : 4;
-    unsigned head : 4;
-  } byte2;
-  struct {
-    unsigned prev : 16;
-    unsigned data : 6;
-    unsigned head : 2;
-  } byte3;
-  char bytes[3];
-};
-
 /**
 This will encode a byte array (data) of a specified length (len) and
 place the encoded data into the target byte buffer (target). The target buffer
@@ -75,45 +54,41 @@ Returns the number of bytes actually written to the target buffer
 A NULL terminator char is NOT written to the target buffer.
 */
 int bscrypt_base64_encode(char *target, const char *data, int len) {
-  int written = 0;
-  // // optional implementation: allow a non writing, length computation.
-  // if (!target)
-  //   return (len % 3) ? (((len + 3) / 3) * 4) : (len / 3);
-  // use a union to avoid padding issues.
-  union base64_parser_u *section;
-  while (len >= 3) {
-    section = (void *)data;
-    target[0] = base64_encodes[section->byte1.data];
-    target[1] =
-        base64_encodes[(section->byte1.tail << 4) | (section->byte2.head)];
-    target[2] =
-        base64_encodes[(section->byte2.tail << 2) | (section->byte3.head)];
-    target[3] = base64_encodes[section->byte3.data];
-
-    target += 4;
-    data += 3;
-    len -= 3;
-    written += 4;
+  /* walk backwards, allowing fo inplace decoding (target == data) */
+  int groups = len / 3;
+  const int mod = len - (groups * 3);
+  const int target_size = (groups + (mod != 0)) * 4;
+  char *writer = target + target_size - 1;
+  const char *reader = data + len - 1;
+  writer[1] = 0;
+  switch (mod) {
+  case 2: {
+    char tmp2 = *(reader--);
+    char tmp1 = *(reader--);
+    *(writer--) = '=';
+    *(writer--) = base64_encodes[((tmp2 & 15) << 2)];
+    *(writer--) = base64_encodes[((tmp1 & 3) << 4) | ((tmp2 >> 4) & 15)];
+    *(writer--) = base64_encodes[(tmp1 >> 2) & 63];
+  } break;
+  case 1: {
+    char tmp1 = *(reader--);
+    *(writer--) = '=';
+    *(writer--) = '=';
+    *(writer--) = base64_encodes[(tmp1 & 3) << 4];
+    *(writer--) = base64_encodes[(tmp1 >> 2) & 63];
+  } break;
   }
-  section = (void *)data;
-  if (len == 2) {
-    target[0] = base64_encodes[section->byte1.data];
-    target[1] =
-        base64_encodes[(section->byte1.tail << 4) | (section->byte2.head)];
-    target[2] = base64_encodes[section->byte2.tail << 2];
-    target[3] = '=';
-    target += 4;
-    written += 4;
-  } else if (len == 1) {
-    target[0] = base64_encodes[section->byte1.data];
-    target[1] = base64_encodes[section->byte1.tail << 4];
-    target[2] = '=';
-    target[3] = '=';
-    target += 4;
-    written += 4;
+  while (groups) {
+    groups--;
+    const char tmp3 = *(reader--);
+    const char tmp2 = *(reader--);
+    const char tmp1 = *(reader--);
+    *(writer--) = base64_encodes[tmp3 & 63];
+    *(writer--) = base64_encodes[((tmp2 & 15) << 2) | ((tmp3 >> 6) & 3)];
+    *(writer--) = base64_encodes[(((tmp1 & 3) << 4) | ((tmp2 >> 4) & 15))];
+    *(writer--) = base64_encodes[(tmp1 >> 2) & 63];
   }
-  target[0] = 0; // NULL terminator
-  return written;
+  return target_size;
 }
 
 /**
@@ -136,60 +111,70 @@ Returns the number of bytes actually written to the target buffer (excluding
 the NULL terminator byte).
 */
 int bscrypt_base64_decode(char *target, char *encoded, int base64_len) {
-  if (base64_len <= 0)
-    return -1;
   if (!target)
     target = encoded;
-  union base64_parser_u section;
+  if (base64_len <= 0) {
+    target[0] = 0;
+    return 0;
+  }
   int written = 0;
-  // base64_encodes
-  // a struct that will be used to read the data.
-  while (base64_len >= 4) {
-    base64_len -= 4; // make sure we don't loop forever.
-    // copying the data allows us to write destructively to the same buffer
-    section.byte1.data = base64_decodes[(unsigned char)(*encoded)];
-    encoded++;
-    section.byte1.tail = (base64_decodes[(unsigned char)(*encoded)] >> 4);
-    section.byte2.head = base64_decodes[(unsigned char)(*encoded)];
-    encoded++;
-    section.byte2.tail = (base64_decodes[(unsigned char)(*encoded)] >> 2);
-    section.byte3.head = base64_decodes[(unsigned char)(*encoded)];
+  char tmp1, tmp2, tmp3, tmp4;
+  while (*encoded == '\r' || *encoded == '\n' || *encoded == ' ') {
+    base64_len--;
     encoded++;
-    section.byte3.data = base64_decodes[(unsigned char)(*encoded)];
-    encoded++;
-    // write to the target buffer
-    *(target++) = section.bytes[0];
-    *(target++) = section.bytes[1];
-    *(target++) = section.bytes[2];
-    // count written bytes
-    written += section.bytes[2] ? 3 : section.bytes[1] ? 2 : 1;
   }
-  // deal with the "tail" of the encoded stream
-  if (base64_len) {
-    // zero out data
-    section.bytes[0] = 0;
-    section.bytes[1] = 0;
-    section.bytes[2] = 0;
-    // byte 1 + 2 (2 might be padding)
-    section.byte1.data = base64_decodes[(unsigned char)*(encoded++)];
-    if (--base64_len) {
-      section.byte1.tail = base64_decodes[(unsigned char)(*encoded)] >> 4;
-      section.byte2.head = base64_decodes[(unsigned char)(*encoded)];
+  while (base64_len >= 4) {
+    tmp1 = *(encoded++);
+    tmp2 = *(encoded++);
+    tmp3 = *(encoded++);
+    tmp4 = *(encoded++);
+    *(target++) = (base64_decodes[(size_t)tmp1] << 2) |
+                  (base64_decodes[(size_t)tmp2] >> 4);
+    *(target++) = (base64_decodes[(size_t)tmp2] << 4) |
+                  (base64_decodes[(size_t)tmp3] >> 2);
+    *(target++) =
+        (base64_decodes[(size_t)tmp3] << 6) | (base64_decodes[(size_t)tmp4]);
+    // make sure we don't loop forever.
+    base64_len -= 4;
+    // count written bytes
+    written += 3;
+    // skip white space
+    while (base64_len &&
+           (*encoded == '\r' || *encoded == '\n' || *encoded == ' ')) {
+      base64_len--;
       encoded++;
-      if (--base64_len) {
-        section.byte2.tail = base64_decodes[(unsigned char)(*encoded)] >> 4;
-        section.byte3.head = base64_decodes[(unsigned char)(*encoded)];
-        // --base64_len;  // will always be 0 at this point (or it was 4)
-      }
     }
-    // write to the target buffer
-    *(target++) = section.bytes[0];
-    if (section.bytes[1] || section.bytes[2])
-      *(target++) = section.bytes[1];
-    if (section.bytes[2])
-      *(target++) = section.bytes[2];
-    // count written bytes
-    written += section.bytes[2] ? 3 : section.bytes[1] ? 2 : 1;
+  }
+  // deal with the "tail" of the mis-encoded stream - this shouldn't happen
+  tmp1 = 0;
+  tmp2 = 0;
+  tmp3 = 0;
+  tmp4 = 0;
+  switch (base64_len) {
+  case 1:
+    tmp1 = *(encoded++);
+    *(target++) = base64_decodes[(size_t)tmp1];
+    written += 1;
+    break;
+  case 2:
+    tmp1 = *(encoded++);
+    tmp2 = *(encoded++);
+    *(target++) = (base64_decodes[(size_t)tmp1] << 2) |
+                  (base64_decodes[(size_t)tmp2] >> 6);
+    *(target++) = (base64_decodes[(size_t)tmp2] << 4);
+    written += 2;
+    break;
+  case 3:
+    tmp1 = *(encoded++);
+    tmp2 = *(encoded++);
+    tmp3 = *(encoded++);
+    *(target++) = (base64_decodes[(size_t)tmp1] << 2) |
+                  (base64_decodes[(size_t)tmp2] >> 6);
+    *(target++) = (base64_decodes[(size_t)tmp2] << 4) |
+                  (base64_decodes[(size_t)tmp3] >> 2);
+    *(target++) = base64_decodes[(size_t)tmp3] << 6;
+    written += 3;
+    break;
   }
   *target = 0;
   return written;
@@ -218,6 +203,13 @@ void bscrypt_test_base64(void) {
       {"any carnal pleasure.", "YW55IGNhcm5hbCBwbGVhc3VyZS4="},
       {"any carnal pleasure", "YW55IGNhcm5hbCBwbGVhc3VyZQ=="},
       {"any carnal pleasur", "YW55IGNhcm5hbCBwbGVhc3Vy"},
+      {"", ""},
+      {"f", "Zg=="},
+      {"fo", "Zm8="},
+      {"foo", "Zm9v"},
+      {"foob", "Zm9vYg=="},
+      {"fooba", "Zm9vYmE="},
+      {"foobar", "Zm9vYmFy"},
       {NULL, NULL} // Stop
   };
   int i = 0;