`houdini_unescape_url` for `%2B` returns whitespace (`0x20`) rather than `+` (`0x2b`)

[nickbruun]

While a literal + should be unescaped to a white space, an encoded + should be unescaped to a literal + and not a white space as is the current behaviour of houdini.

A quick demonstration:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#include "houdini.h"

int main(int argc, char* argv[])
{
    const uint8_t *escaped = (uint8_t *)"+%2B";
    gh_buf unescaped = GH_BUF_INIT;

    if (houdini_unescape_url(&unescaped, escaped, 4) == 0)
    {
        fprintf(stderr, "Expected the escaped string to be unescaped\n");
        return EXIT_FAILURE;
    }

    if (strcmp(gh_buf_cstr(&unescaped), " +") != 0)
    {
        fprintf(stderr, 
                "Expected the unescaped string to have a value of \" +\" but "
                "a value of \"%s\" was returned\n", 
                gh_buf_cstr(&unescaped));
        return EXIT_FAILURE;
    }

    return EXIT_SUCCESS;
}

The output as produced by $ clang -lhoudini test_plus.c -o test_plus -Wall -pedantic && ./test_plus under Mac OS X 10.8 with clang 4.0 (LLVM 3.1) with test_plus.c being the above source code:

$ clang -lhoudini test_plus.c -o test_plus -Wall -pedantic && ./test_plus
Expected the unescaped string to have a value of " +" but a value of "  " was returned

Is this behaviour intentional?

[nickbruun]

The problem seems to be that substitution of literal + with white space is done after the unescaping has been performed thus converting both literal and previously escaped +'s to white space.

Update: Upon further investigation, + will not be replaced with white space if no characters have been escaped in the current implementation either. Pull request #11 fixes this problem as well.

[ptoomey3]

This should be fixed as of #16.