[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Bug in base64, new module base32

From: Gijs van Tulder
Subject: Bug in base64, new module base32
Date: Wed, 10 Aug 2011 15:54:21 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11


I'd like to send you two patches that are related to the base64 module. I hope you find them useful.


The first patch fixes a bug (or at least, I think it is a bug) in the base64_decode_alloc_ctx function. This method sometimes does not decode the final byte in the input. Strange enough, this bug was mentioned in the tests but not fixed.

Example (from the tests):

YWJjZGVmZ2hp   decodes to   abcdefghi

If you initialize a new decode-context buffer ctx and run:

base64_decode_alloc_ctx (&ctx, "YW", ...)
  ->  decodes nothing (that's OK)
      "YW" is kept in the decode-context buffer

base64_decode_alloc_ctx (&ctx, "JjZGVmZ2", ...)
  ->  decodes abcdef  (OK, that's "YWJjZGVm")
      now the decode-context buffer contains "Z2"

then, finally:

base64_decode_alloc_ctx (&ctx, "hp", ...)
  ->  decodes gh  (not OK, where's the final 'i'?)

I think this is because the base64_decode_alloc_ctx does not allocate enough space in the output buffer, because it doesn't look at what is already in the decode-context buffer. I found that if I add one extra byte to the buffer size it works. (See patch 1.)


The reason I found this bug was that I was working on a base32 module. I need a base32 encoding/decoding module, but Gnulib doesn't have one. In patch 2, I included a new module based on the base64 code that is already in Gnulib.

Kind regards,

Gijs van Tulder

Attachment: 0001-base64_decode_alloc_ctx-would-sometimes-miss-the-fin.patch
Description: Text Data

Attachment: 0002-New-module-base32.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]