client9/stringencoders

Fast c-string transformations

stringencoders's Issues

Is it possible to get higher precision then 9 when using mod_dtoa/mod_dtoa2?

Nick,

I see in the code the following restriction:

    if (prec < 0) {
        prec = 0;
    } else if (prec > 9) {
        /* precision of >= 10 can lead to overflow errors */
        prec = 9;
    }

and

    /* if input is larger than thres_max, revert to exponential */
    const double thres_max = (double)(0x7FFFFFFF);


Could max prec and thres_max be raised? Do I understand correctly that the 
problem is caused by the fact that the code is not using int64_t/uint64_t here:

    int whole = (int) value;
    ...
    uint32_t frac = (uint32_t)(tmp);

Is there any good reason not to switch to 64 bit integers here and allow higher 
prec and thres_max? I'm willing to write a patch but I was just wondering if 
I'm missing something.

Original issue reported on code.google.com by [email protected] on 10 Jun 2010 at 9:00

Em Dash character causes an exception in base64.js

What steps will reproduce the problem?
1. var Value = base64.encode('Budget – 5 simple steps');
2. the - is actually the EM Dash character
3.

What is the expected output? What do you see instead?
Expected to see: 'QnVkZ2V0IOKAkyA1IHNpbXBsZSBzdGVwcw==' (according to 
http://www.base64encode.org/)
Instead received an exception and the script stopped running

What version of the product are you using? On what operating system?
base64.js, r230, Mar 29, 2010, nickgsuperstar

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 27 Feb 2014 at 4:19

Patch for 64-bit compilation

Hi Nick,

Hope you're doing well

When I've tried to compile modp in 64-bit env, I've found it generates a lot of 
warnings due to the fact that some types in 64-bit have different length 
compared to 32-bit env, but some types have the same lengh.

So I've patched modp to make it compilable under 64-bit w/o warnings. Patch is 
attached.

Original issue reported on code.google.com by [email protected] on 26 Aug 2011 at 3:06

Attachments:

• modp.64bit.diff

not an issue just: new proposal for modp_stdint.h again

again 8) happy new year!

Original issue reported on code.google.com by [email protected] on 17 Feb 2015 at 1:01

Attachments:

• modp_stdint.h

No tests for Inf/Nan in modp_dtoa, modp_dtoa2

There are no tests for Inf or Nan values in modp_dtoa/2.

tests need to be added, and code changed appropriately.

Original issue reported on code.google.com by [email protected] on 19 Mar 2010 at 2:06

bus error on solaris in base64_decode()

What steps will reproduce the problem?
1. build on sparc (i suppose any platform that doesn't forgive unaligned writes)
2. run speedtest
3. you'll get bus error on decode test (the second line)

> What version of the product are you using? On what operating system?
$ uname -a
SunOS [] 5.10 Generic_118833-24 sun4v sparc SUNW,Sun-Fire-T200

my guess this happens because of unaligned write in modp_b64.c line 152
specificaly this fragment worries me:
        *destInt = x << 8;
        p += 3;
        destInt = (uint32_t*)p;

(here at some point you'll have uint32_t* pointing to p + 3, p + 6, etc.) and 
bang.

Original issue reported on code.google.com by [email protected] on 21 Jun 2007 at 3:35

Corruption of const input string that use C.O.W.

GCC-4.6 seems to use C.O.W. (Copy-On-Write) for std::strings.
When calling std::string modp::b85_decode(const std::string& s), the input 
string s is corrupted.
This is due to the fact that although 's' is "copied" into an internal copy 
'x', the copy is not really done. A further call to the non-const b85_decode() 
corrupts s, since it uses const_cast to strip the const from the .data() 
returned results (presumably to avoid a copy at all costs on all 
implementations).

What steps will reproduce the problem?
1. On gcc (with C.O.W.), pass an std::string 's' to modp::b85_decode(const 
std::string& s);
2. 's' is now corrupted.

What is the expected output? What do you see instead?
A call to a function that accepts const should not alter the const argument.

What version of the product are you using? On what operating system?
gcc 4.6 on Linux.

Please provide any additional information below.

One possible fix is to change the implementation to:
     inline std::string b85_decode(const std::string& s)
     {
         // std::string x(s); // original impl.
         std::string x(s.data(), s.size()); // new impl. - force copy even with COW
         b85_decode(x);
         return x;
     }

Original issue reported on code.google.com by [email protected] on 1 Nov 2012 at 8:37

revert mopd_stdint

revert mopd_stdint

Original issue reported on code.google.com by [email protected] on 3 Jan 2012 at 10:24

Windows STD_INT > vc 6

Windows STD_INT > vc 6

http://www.azillionmonkeys.com/qed/pstdint.h

Original issue reported on code.google.com by [email protected] on 1 Jun 2011 at 12:24

modp_dtoa may exceed precision due to rounding

If you convert certain fractions - say 0.09999999 to precision 6 - the code 
will round up to 0.1000000 (999999 is the fraction part, plus 1 for the 
rounding). This produces 7 digits past the decimal.

Looks like modp_dtoa2 handles this indirectly, but it might make sense to check 
if the rounding causes a carry, and if so, to divide by 10.

Original issue reported on code.google.com by [email protected] on 29 Dec 2010 at 4:38

copying versions of C++ functions tolower(), toupper(), toprint() modify original string

The code for these functions look like

    inline std::string tolower(const std::string& str)
    {
        std::string s(str);
        modp_tolower_copy(const_cast<char*>(s.c_str()), s.data(), s.size());
        return s;
    }

This as I understand supposed to copy original string into another variable and 
do all modifications in the copy of the original string. Unfortunately at least 
in some STL implementations this actually changes the original string (for 
example in STL included into gcc-4.4). This is because the library uses copy on 
write for STL strings and s.c_str() actually points to exactly same memory 
space as str.c_str() what means that any direct operations on s.c_str() change 
the original string. This is a bug in stringencoders because strictly speaking 
the standard doesn't allow for modifications  of the storage returned by 
c_str(). See for example 
http://www.cplusplus.com/reference/string/string/c_str/. Quote: "The returned 
array points to an internal location with the required storage space for this 
sequence of characters plus its terminating null-character, but the values in 
this array should not be modified in the program ...".

The below implementation still violates the standard but at least it doesn't 
break on gcc-4.4:

    inline std::string tolower(const std::string& str)
    {
        std::string s(str.size() + 1, '\0');
        modp_tolower_copy(const_cast<char*>(s.c_str()), str.data(), str.size());
        return s;
    }

Original issue reported on code.google.com by [email protected] on 12 Jul 2011 at 11:11

In some cases modp_dtoa/modp_dtoa2 gives different precision then requested

Nick,

The code has the following branch:

    if (value > thres_max) {
        sprintf(str, "%e", neg ? -value : value);
        return;
    }

This is wrong as it ignores requested precision - sprintf uses 6 precision by 
default.

Original issue reported on code.google.com by [email protected] on 10 Jun 2010 at 8:56

package version mismatch

What steps will reproduce the problem?

config.h.in

v3.8.0

package version is still defined to 3.7.0 should be 3.8.0

#define PACKAGE_STRING "stringencoders v3.7.0"

/* Define to the one symbol short name of this package. */
#define PACKAGE_TARNAME "stringencoders"

/* Define to the version of this package. */
#define PACKAGE_VERSION "v3.7.0"

/* Define to 1 if you have the ANSI C header files. */
#define STDC_HEADERS 1

/* Version number of package */
#define VERSION "v3.7.0"

Original issue reported on code.google.com by [email protected] on 6 Feb 2010 at 2:39

Attachments:

• config.h

Patch for /trunk/javascript/base64.js

/*
 * Copyright (c) 2010 Nick Galbreath
 * http://code.google.com/p/stringencoders/source/browse/#svn/trunk/javascript
 *
 * Permission is hereby granted, free of charge, to any person
 * obtaining a copy of this software and associated documentation
 * files (the "Software"), to deal in the Software without
 * restriction, including without limitation the rights to use,
 * copy, modify, merge, publish, distribute, sublicense, and/or sell
 * copies of the Software, and to permit persons to whom the
 * Software is furnished to do so, subject to the following
 * conditions:
 *
 * The above copyright notice and this permission notice shall be
 * included in all copies or substantial portions of the Software.
 *
 * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
 * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
 * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
 * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
 * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
 * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
 * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
 * OTHER DEALINGS IN THE SOFTWARE.
 */

/* base64 encode/decode compatible with window.btoa/atob
 *
 * window.atob/btoa is a Firefox extension to convert binary data (the "b")
 * to base64 (ascii, the "a").
 *
 * It is also found in Safari and Chrome.  It is not available in IE.
 *
 * if (!window.btoa) window.btoa = base64.encode
 * if (!window.atob) window.atob = base64.decode
 *
 * The original spec's for atob/btoa are a bit lacking
 * https://developer.mozilla.org/en/DOM/window.atob
 * https://developer.mozilla.org/en/DOM/window.btoa
 *
 * window.btoa and base64.encode takes a string where charCodeAt is [0,255]
 * If any character is not [0,255], then an DOMException(5) is thrown.
 *
 * window.atob and base64.decode take a base64-encoded string
 * If the input length is not a multiple of 4, or contains invalid characters
 *   then an DOMException(5) is thrown.
 */
var base64 = {};
base64.PADCHAR = '=';
base64.ALPHA = 
'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/';

base64.makeDOMException = function() {
    // sadly in FF,Safari,Chrome you can't make a DOMException
    var e, tmp;

    try {
        return new DOMException(DOMException.INVALID_CHARACTER_ERR);
    } catch (tmp) {
        // not available, just passback a duck-typed equiv
        // https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Global_Objects/Error
        // https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Global_Objects/Error/prototype
        var ex = new Error("DOM Exception 5");

        // ex.number and ex.description is IE-specific.
        ex.code = ex.number = 5;
        ex.name = ex.description = "INVALID_CHARACTER_ERR";

        // Safari/Chrome output format
        ex.toString = function() { return 'Error: ' + ex.name + ': ' + ex.message; };
        return ex;
    }
}

base64.getbyte64 = function(s,i) {
    // This is oddly fast, except on Chrome/V8.
    //  Minimal or no improvement in performance by using a
    //   object with properties mapping chars to value (eg. 'A': 0)
    var idx = base64.ALPHA.indexOf(s.charAt(i));
    if (idx === -1) {
        throw base64.makeDOMException();
    }
    return idx;
}

base64.decode = function(s) {
    // convert to string
    s = '' + s;
    var getbyte64 = base64.getbyte64;
    var pads, i, b10;
    var imax = s.length
    if (imax === 0) {
        return s;
    }

    if (imax % 4 !== 0) {
        throw base64.makeDOMException();
    }

    pads = 0
    if (s.charAt(imax - 1) === base64.PADCHAR) {
        pads = 1;
        if (s.charAt(imax - 2) === base64.PADCHAR) {
            pads = 2;
        }
        // either way, we want to ignore this last block
        imax -= 4;
    }

    var x = [];
    for (i = 0; i < imax; i += 4) {
        b10 = (getbyte64(s,i) << 18) | (getbyte64(s,i+1) << 12) |
            (getbyte64(s,i+2) << 6) | getbyte64(s,i+3);
        x.push(String.fromCharCode(b10 >> 16, (b10 >> 8) & 0xff, b10 & 0xff));
    }

    switch (pads) {
    case 1:
        b10 = (getbyte64(s,i) << 18) | (getbyte64(s,i+1) << 12) | (getbyte64(s,i+2) << 6);
        x.push(String.fromCharCode(b10 >> 16, (b10 >> 8) & 0xff));
        break;
    case 2:
        b10 = (getbyte64(s,i) << 18) | (getbyte64(s,i+1) << 12);
        x.push(String.fromCharCode(b10 >> 16));
        break;
    }
    return x.join('');
}

base64.getbyte = function(s,i) {
    var x = s.charCodeAt(i);
    if (x > 255) {
        throw base64.makeDOMException();
    }
    return x;
}

base64.encode = function(s) {
    if (arguments.length !== 1) {
        throw new SyntaxError("Not enough arguments");
    }
    var padchar = base64.PADCHAR;
    var alpha   = base64.ALPHA;
    var getbyte = base64.getbyte;

    var i, b10;
    var x = [];

    // convert to string
    s = '' + s;

    var imax = s.length - s.length % 3;

    if (s.length === 0) {
        return s;
    }
    for (i = 0; i < imax; i += 3) {
        b10 = (getbyte(s,i) << 16) | (getbyte(s,i+1) << 8) | getbyte(s,i+2);
        x.push(alpha.charAt(b10 >> 18));
        x.push(alpha.charAt((b10 >> 12) & 0x3F));
        x.push(alpha.charAt((b10 >> 6) & 0x3f));
        x.push(alpha.charAt(b10 & 0x3f));
    }
    switch (s.length - imax) {
    case 1:
        b10 = getbyte(s,i) << 16;
        x.push(alpha.charAt(b10 >> 18) + alpha.charAt((b10 >> 12) & 0x3F) +
               padchar + padchar);
        break;
    case 2:
        b10 = (getbyte(s,i) << 16) | (getbyte(s,i+1) << 8);
        x.push(alpha.charAt(b10 >> 18) + alpha.charAt((b10 >> 12) & 0x3F) +
               alpha.charAt((b10 >> 6) & 0x3f) + padchar);
        break;
    }
    return x.join('');
}

Original issue reported on code.google.com by [email protected] on 3 Sep 2012 at 2:02

Attachments:

• base64.js.patch

some references to string missing std:: prefix

In the header files (at least in modp_b64.h and modp_b16.h, which are the
two I'm using), there are some references to string that should be std::string

Original issue reported on code.google.com by [email protected] on 4 Jan 2008 at 6:44

configure and config.h.in should not be svn

For development svn is used. configure and config.h.in are generated 
automatically via autoconf tools. They should be removed from svn. For released 
taballs only they should be generated using may be 'make dist' or something 
similar.

svn status shows:
M       configure
M       config.h.in

without me making any changes. This should not happen in development checkout.

Regards,

Original issue reported on code.google.com by [email protected] on 24 Feb 2012 at 8:18

Another variant of modp_dtoa which removes trailing zeros from output

Hi Nick,

This is Ilya Martynov, perhaps you still remember me :)

We are you using your library at iponweb with a small patch to modp_dtoa
which changes it to remove trailing zeros from its output. The patch is
trivial:

--- modp_numtoa.c.orig  2010-03-18 12:24:40.000000000 +0300
+++ modp_numtoa.c   2010-03-18 12:27:59.000000000 +0300
@@ -141,9 +141,14 @@
             /* 1.5 -> 2, but 2.5 -> 2 */
             ++whole;
         }
-    } else {
+    } else if (frac) {
         int count = prec;
         // now do fractional part, as an unsigned number
+        // we know it is not 0 but we can have leading zeros, these should
be removed
+        while (!(frac % 10)) {
+            --count;
+            frac /= 10;
+        }
         do {
             --count;
             *wstr++ = (char)(48 + (frac % 10));

It would be nice if it was integrated into your library in some form.
Perhaps modp_dtoa() should have a boolean flag to let user choose between
removing or keeping trailing zeros? I'm not sure on the best API to support
both current and this logic.

Original issue reported on code.google.com by [email protected] on 18 Mar 2010 at 9:42

modp_b64_gen.c generates two identical char arrays

The following two lines generate two identical char arrays.

stringencoders/src/modp_b64_gen.c

Line 87 in e1448a9

char_array_to_c(cary, sizeof(cary), "e1");

stringencoders/src/modp_b64_gen.c

Line 92 in e1448a9

char_array_to_c(cary, sizeof(cary), "e2");

One called e1 and the other e2.
I can't figure out what's the use two identical array literals.
They appear to be used only in the function modp_b64_encode which could work well with only one of them.

Is this deliberate?
For what purpose?

Please document required alignment for modp_b64_decode()

What steps will reproduce the problem?
1. Call modp_b64_decode() with src or dest not 4-byte aligned.
2. Code hangs when the unaligned pointer is cast to uint32 (srcInt/destInt).

What is the expected output? What do you see instead?
On inspecting the code, I understand this is expected. I'm just asking for it 
to be documented in the function comments.

What version of the product are you using? On what operating system?
ARMCC compiler in Keil uVision. MQX 4.1.0 OS.

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 1 Apr 2015 at 9:58

Patch for /trunk/javascript/base64-speed.html

4529E147B211E1917F1994A1910F2036B1980B1924C1987E2029F1539F2050D2015C1952A2029E19
24C1497D1455A1637A1973E1952F1987D1966D1441A1945C2015B1924F1931F1644F1490D1945A20
29D2029E2001B2022B1623C1546E1546F1938D1994B1994C1938C1973C1924B1917D2015E1952E20
43C1924D1539D1910C1994C1980F1546A1945F1994E2022B2029E1546D1553A1679B1532C1812F17
07C1763D1686E2022B1966C1700E1973C1602C1784E1917E1567C1588A1798C1756F1812F1763A20
22F1924D1707D1707F1777B1784C1966B1966A1490A1441C2015C1924E1973C1644E1490E2022F20
29B2064B1973F1924E2022B1945E1924F1924C2029E1490C1441E2029C2064A2001C1924F1644F14
90F2029C1924B2057B2029B1546E1910A2022A2022D1490C1546F1651E1455E1504F1630B1287E14
69F1497F1917E1994A1910C2036A1980F1924E1987C2029E1504E1539A2015B1924B1896E1917A20
64C1497A1931C2036E1987F1910A2029B1952A1994A1987C1441F1497B1504F1441D2078C1287E14
41E1469B1497A1490F1462C2029C1924F1980D2001E1973C1896E2029A1924D1952B1931E2064D14
90C1504D1539B1945C2029B1980B1973E1497B1490D1637D1896A1441B1945F2015E1924E1931E16
44D1455C1945C2029B2029C2001E1623A1546A1546D2050A2050E2050D1539B2029A1924F1980F20
01C1973A1896B2029F1924E1952A1931C2064B1539E1910D1994F1980C1455E1651D1805C1924C19
80A2001A1973D1896B2029A1924E1952B1931A2064F1637B1546D1896B1651B1490E1504A1630B12
87D1441D2022D1924C2029C1728E1987F2029E1924B2015F2043C1896B1973F1497A1931C2036F19
87E1910C2029D1952D1994B1987F1441D1497E1504A1441D2078F1287B1441A1441B1441E1441A14
41C1952E1931C1441B1497E1448E1469F1497F1490F1462D2029F1924B1980F2001B1973A1896B20
29D1924B1952C1931F2064C1623F2043A1952E2022A1952F1903F1973D1924C1490E1504C1539C19
73D1924B1987B1938F2029D1945B1504C1441B2050B1952B1987E1917A1994C2050F1539B1973D19
94E1910C1896E2029C1952B1994E1987F1539A1945F2015B1924D1931D1441A1644C1441A1490B19
45A2029F2029D2001E1623C1546A1546E2050A2050F2050A1539A2029E1924C1980F2001B1973D18
96F2029B1924A1952B1931B2064A1539F1910B1994F1980E1490F1287E1441F2092A1525A1441E15
60C1553C1553E1553E1504A1287C2092D1504F1287E1469F1497E1917C1994E1910A2036C1980C19
24B1987E2029D1504D1539B2015E1924F1896B1917F2064F1497C1931D2036E1987A1910A2029D19
52B1994C1987F1441F1497A1504D1441F2078D1287E1441E1469D1497D1490E1462E2022B2001D19
94A1987F2022C1994C2015C2022D1945A1952B2001C1490D1504D1539D1945D2029B1980A1973C14
97C1490E1637A1896A1441E1945C2015D1924D1931D1644E1455A1945E2029D2029F2001E1623E15
46D1546B2050A2050F2050A1539D2029A1924A1980A2001A1973C1896D2029A1924D1952E1931E20
64B1539A1910B1994F1980C1546B2001E1546A2022C2001A1994C1987C2022C1994C2015A2022D19
45F1952C2001B1539D1945E2029E1980B1973D1455B1651A1840E1994B2036D2015F1441F1749B19
52B1987D1966F1441A1721B1924C2015A1924C1637B1546A1896A1651F1490A1504F1630A1287C14
41E2022E1924B2029A1728D1987F2029A1924F2015C2043F1896B1973C1497A1931E2036D1987D19
10A2029A1952D1994C1987D1441C1497B1504B1441A2078C1287F1441D1441D1441B1441D1441A19
52E1931B1441B1497F1448A1469B1497C1490C1462B2022E2001D1994D1987B2022A1994D2015E20
22E1945E1952B2001D1623C2043C1952F2022C1952C1903B1973A1924B1490E1504F1539A1973A19
24C1987C1938B2029F1945F1504D1441F2050D1952B1987A1917E1994D2050E1539D1973D1994F19
10E1896B2029C1952A1994D1987D1539C1945C2015F1924E1931F1441D1644E1441F1490A1945C20
29D2029E2001E1623D1546A1546E2050E2050D2050B1539A2029B1924B1980B2001A1973B1896C20
29A1924A1952D1931F2064F1539F1910F1994E1980E1490D1287F1441A2092E1525B1441B1560C15
53C1553F1553B1504F1287C2092F1504D

Original issue reported on code.google.com by [email protected] on 8 Dec 2013 at 10:42

Attachments:

• base64-speed.html.patch

modp_litoa10 truncates value if sizeof(unsigned long) is not 8

The modp_litoa10 does the majority of its work on uvalue, which is an unsigned 
long.  If an unsigned long is not 64-bits wide, the input number will be 
truncated. 

    unsigned long uvalue = (value < 0) ? -value : value;

Fix:  Change the declaration of uvalue to uint64_t.

    uint64_t uvalue = (value < 0) ? -value : value;

Original issue reported on code.google.com by [email protected] on 9 Feb 2012 at 8:25

modp_dtoa() fails for input of 0.95 with precision of 1

What steps will reproduce the problem?
1. call modp_dtoa(1.95, s, 1);
2. call modp_dtoa(0.95, s, 1);
3. call modp_dtoa(0.9999995, s, 6);

What is the expected output? What do you see instead?
1. s = "1.1"
2. s = "1.0"
3. s = "1.0"

What do you see instead?
1. s = "1.10"
2. s = "0.1"
3. s = "0.1"

What version of the product are you using? On what operating system?
Windows 7, TDM-GCC 4.8.1 64-bit with -std=C99 

Please provide any additional information below.
This causes issues for any values where the fractional part is recurring 9's 
followed by a 5 and the precision length would cut off the 5.

Original issue reported on code.google.com by [email protected] on 10 Dec 2014 at 12:55

Library fails to build on sparc,powerpc,arm because of bad casting in the test suite

The current version of the library fails to build on some platforms which can 
be seen here:
https://buildd.debian.org/status/package.php?p=stringencoders

The bug was reported via debian bugs:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695024
The report also contains a patch to fix this bug.

Original issue reported on code.google.com by [email protected] on 7 Dec 2012 at 7:09

Duplicate base64 encoding tables?

I notice the e1 and e2 encoding tables are the same thing byte for byte. Is 
that intentional (if so why have e2 at all? I ditched it when I ported the 
code) or was it a typo?

Original issue reported on code.google.com by [email protected] on 19 Mar 2013 at 12:58

dtoa & dtoa2 lose a fractional leading '0'

What steps will reproduce the problem?
1. Call: "modp_dtoa2(1.03, str, 2);"
2.  Call: "modp_dtoa2(1.003, str, 2);"

What is the expected output? 
1. "1.03" 
2. "1.003"

What do you see instead?
1. "1.3"
2. "1.03"

What version of the product are you using? On what operating system?
r445

Please provide any additional information below.
Ln# 287 should be >= not >

Original issue reported on code.google.com by [email protected] on 23 Jul 2014 at 12:18

compilation errors on intel mac regarding modp_b64.c

What steps will reproduce the problem?
1. #include "stdint.h" or #include "modp_stdint.h" should be in modp_b64.c
2. CHARPAD is not defined, assuming #define CHARPAD '=' should be inserted 
above #ifndef DOPAD
3. 'e0' undeclared error and  also modp_b64.c:219: - modp_b64.c:222:

What is the expected output? What do you see instead?
Cant solve #3

What version of the product are you using? On what operating system?
Mac OS X 10.5.6 Intel GCC 4.0/4.2

Please provide any additional information below.
For example: *p++ = e0[t1]; //if never seen this syntax, help me out?

Original issue reported on code.google.com by [email protected] on 21 Apr 2012 at 3:26

modp_dtoa returns crap pointer in corner cases

What steps will reproduce the problem?
1. print any double that has a nan, or too big
2.
3.

The corner cases have a simple "return" and it doesn't return a char* which is 
a fatal bug.

Original issue reported on code.google.com by [email protected] on 30 Dec 2011 at 3:07

Patch for /trunk/javascript/base64.js

Added missing semicolon

Original issue reported on code.google.com by [email protected] on 7 Jun 2013 at 1:59

Attachments:

• base64.js.patch

Variant which protects against buffer overflows

Like this: https://github.com/bro/bro/blob/master/src/modp_numtoa.c#L290-L292

End requirement for stdint.h (mainly to work towards a Win32/64 compile)

stdint.h is not supplied on Windows. This is highly unfortunate but it's fairly 
easy to get around.

Attached is a patch that changes all <stdint.h> includes to a "modp_stdint.h". 
The include order is changed to still follow the preferred order of: the 
corresponding .h for this .c, std C stuff, std C++ stuff, system stuff, our 
stuff. If _WIN32 is defined (which is true for Win32/64), we define the 
u?int(8|16|32|64)_t types. Otherwise, #include <stdint.h>.

Nothing other than these types is defined for Windows but that's all that is 
currently necessary, I think. I found no uses of the *_MIN, *_MAX, *_C, macros.

This removes one challenge of adding Windows support.

Original issue reported on code.google.com by [email protected] on 29 Aug 2010 at 9:25

Attachments:

• 0001-win-stdint.patch

Round-to-even bug in modp_dtoa2

We found that modp_dtoa2 has odd cases where it does not properly round-to-even. For example x.665 should be rounded down to x.66 but sometimes it gets rounded to x.67

modp_dtoa2(9.8665, digits = 3)
# 9.867
modp_dtoa2(1.8665, digits = 3)
# 1.866

Or

modp_dtoa2(111.665, digits = 2)
# 111.67
modp_dtoa2(222.665, digits = 2)
# 222.66 
modp_dtoa2(333.665, digits = 2)
# 333.67
modp_dtoa2(444.665, digits = 2)
# 444.67

base32

please add support for base32

Original issue reported on code.google.com by [email protected] on 13 Apr 2012 at 4:46

invalid type used in function: void modp_litoa10(int64_t value, char* str)

In file modp_numtoa.c at line
    unsigned long uvalue = (value < 0) ? -value : value;
input is converted to 32 bit integer.

Solution:
    uint64_t uvalue = (value < 0) ? -value : value;

Original issue reported on code.google.com by [email protected] on 20 Jun 2013 at 8:37

problem in libtool file

CentOS 4.6: in order to successfully build, after ./configure, I have to
edit libtool and remove ~\$RANLIB (2 occurrences).  It seems ranlib is not
necessary, and these two references cause problems because they are
concatenated with the names of the object files that precede them.

Original issue reported on code.google.com by [email protected] on 4 Jan 2008 at 6:42

10^0 is 1, not 0.

in source 
file: modp_numtoa.c
line: ln14 - ln19
------------------------------------------------------------------------
/**
 * Powers of 10
 * 10^0 to 10^9
 */
static const double pow10[] = {0, 10, 100, 1000, 10000, 100000, 1000000,
                               10000000, 100000000, 1000000000};
------------------------------------------------------------------------
The array pow10's first element is 10^0, but why the value is 0?

Original issue reported on code.google.com by [email protected] on 24 Sep 2007 at 4:30

dtoa & dtoa2 should be short-circuited for values of 0.0

A possible enhancement would be to check for a parameter of 0.0 for the value 
argument and then immediately set the str to "0" and return, similar to the NAN 
check.

e.g. for the case: 

"modp_dtoa2(0.0, str, n);"

The implementation may be better off being:

"size_t modp_dtoa2(double value, char * str, int prec) {
    if (!(value == value)) {    /* Test for NAN. */
        str[0] = 'n'; str[1] = 'a'; str[2] = 'n'; str[3] = 0;
        return (size_t) 3;
    }
    if (x = 0.0) {    /* Test for 0.0. */
        str[0] = '0'; str[1] = 0;
        return (size_t) 1;
    }

        //... Rest of implementation as-is...
}

Original issue reported on code.google.com by [email protected] on 23 Jul 2014 at 12:31

valgrind error for modp_b16_encode (patch included)

What steps will reproduce the problem?
1. Use modp_b16_encode with dynamically allocated buffer of length not 
divisible by 4. (Example attached.)
2. Run with valgrind.

What is the expected output? What do you see instead?

Expect no valgrind errors.  See invalid read of size 4 error.


What version of the product are you using? On what operating system?

3.10.3 on OS X 10.7.

Please provide any additional information below.

The problem occurs because once modp_b16_encode has reached the end of its loop 
it does a final read of the next 4 bytes.  Or, if the size is < 4, the 
initialization of x reads 4 bytes.

   // modp_b16_encode.c: 58
   uint32_t x = *srcInt++;

  // modp_b16_encode.c: 80
  x = *srcInt++;

As the buffer contains 1, 2, or 3 remaining bytes, this overflows the buffer 
and causes the valgrind error.  The result is still correct because the 
remaining leftover handling code only looks at the bits of x that were in the 
buffer.  But, the valgrind error is easily avoidable and doing so is both 
satisfying and eases valgrinding of code that uses modp_b16_encode.

A patch is attached that fixes the issue in modp_b16_encode.  I expect that 
many of the other encoders have similar problems, however.

Original issue reported on code.google.com by [email protected] on 28 Nov 2011 at 5:16

Attachments:

• bad_modp_b16_encode.c
• modp_b16.c.patch

silent overflow modp_litoa10 is given LONG_MIN

Thanks for writing this library, I've been using the integer to string
functions successfully w/ great speed gain. But I had to fix a small issue
with both modp_litoa10 and modp_itoa10 functions. When modp_litoa10 is
given the number LONG_MIN, there's an overflow in the "value=-value"
statement, this can be easily solved by making an unsigned long receive the
-value.
Please see the proposed fix in the attachment. The same principle applies
to modp_itoa10.

Original issue reported on code.google.com by [email protected] on 16 Dec 2009 at 2:31

Attachments:

• modp_litoa10.diff.gif

Possible optimization for numbers < 10

Nick, while you're in there... I was thinking there might be another 
optimization for numbers that are less than 10. For these, we know the length 
of the string up front (precision + 2). In this case, can't we avoid the need 
to reverse the string at the end?

Also, to make it easier to use the result, it would be nice to have the return 
value be the # of chars written. Saves a strlen.

Original issue reported on code.google.com by [email protected] on 30 Dec 2010 at 7:27

code does not compile (test cases) with -Werror=unused-but-set-variable (patch to fix it)

Index: test/speedtest.c
===================================================================
--- test/speedtest.c    (revision 241)
+++ test/speedtest.c    (working copy)
@@ -37,7 +37,6 @@
     int i, j;
     clock_t c0, c1;
     char teststr1[SZ];
-    char teststr2[SZ];

     /*
       this contains the message sizes we'll test on
@@ -47,7 +46,6 @@

     for (i = 0; i < (int)sizeof(teststr1); ++i) {
         teststr1[i] = 'A' + i % 26;
-        teststr2[i] = 'A' + i % 26;
     }

     // over allocate result buffers

Original issue reported on code.google.com by [email protected] on 8 Feb 2012 at 12:07

Few suggested improvements

Hi, thank you for your project.

I want to make few improvements and merge them upstream.
However some of them are subjective and might impose minor breaking changes.
I'd like to hear your opinion first before writing code.

I summarised proposed changes in my fork:
https://github.com/hyperblast/stringencoders/issues

Thanks in advance.

Build failure

Hi Nick again,

The latest release fails to build on some of our boxes:

cc1: warnings being treated as errors
test/modp_numtoa_test.c: In function 'testDTOANonFinite':
test/modp_numtoa_test.c:338: error: unused variable 'buf1'

The following trivial patch fixes the problem:

diff --git a/3rdparty/modp/test/modp_numtoa_test.c
b/3rdparty/modp/test/modp_numtoa_test.c
--- a/3rdparty/modp/test/modp_numtoa_test.c
+++ b/3rdparty/modp/test/modp_numtoa_test.c
@@ -336,6 +336,7 @@
 // Test NaN and Infinity behavior
 static char* testDTOANonFinite() {
     char buf1[100];
+    (void)buf1;
     char buf2[100];
     double d;

For the record this happens with Debian Lenny. Apparently it doesn't define
INFINITY macro so the code where buf1 is used doesn't get to compile and
thus we get unused variable warning.

Original issue reported on code.google.com by [email protected] on 25 Mar 2010 at 4:16

modp_b64_data.h is missing

What steps will reproduce the problem?
1. Try to compile modp_b64.c.
2. Compilation fails, missing modp_b64_data.h.

What is the expected output? What do you see instead?

Expected successful compilation. Got error on missing header.

What version of the product are you using? On what operating system?

Mac OS X

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 18 Jul 2011 at 2:27

modp_b64_test.c failed

The following error message is generated by AddressSanitizer:

=================================================================
==25695==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f0495576783 bp 0x7ffc5b00bb10 sp 0x7ffc5b00ba60 T0)
==25695==The signal is caused by a READ memory access.
==25695==Hint: address points to the zero page.
#0 0x7f0495576782 in modp_b64_decode src/modp_b64.c:177
#1 0x55c166594d91 in testEmpty test/modp_b64_test.c:57
#2 0x55c166597849 in all_tests test/modp_b64_test.c:259
#3 0x55c166597a04 in main test/modp_b64_test.c:266
#4 0x7f049539c0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
#5 0x55c16659441d in _start (modp_b64_test.unittest+0x141d)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV src/modp_b64.c:177 in modp_b64_decode
==25695==ABORTING

compilation issue on MS VS2008

What steps will reproduce the problem?
1. try to compile a project using the base64 encoder with MS VS2008
2.
3.

What is the expected output? What do you see instead?
compilation fails

What version of the product are you using? On what operating system?
3.7.0

Please provide any additional information below.
in modp_b64.c (modp_b64_decode) the variables are defined after some 
sanity checking code (line 210) that makes VS2008 go mad, defining the 
variables just after the prototype and then using them after the ifdeffed 
code works fine

Original issue reported on code.google.com by [email protected] on 1 Aug 2009 at 2:05

needs to add works great on iOS

TODO publishing the speed tests on ARM V6/7

Original issue reported on code.google.com by [email protected] on 1 Jan 2012 at 5:49

win32, mingw: Build fails.

Using msys-1.10 the build fails after ./configure:

make  all-am
make[1]: Entering directory `/home/Administrator/stringencoders-v3.7.0'
gcc   modp_b2_gen.o   -o modp_b2_gen
modp_b2_gen.o: In function `hexdecodemap':
C:/msys/1.0/home/Administrator/stringencoders-v3.7.0/src/modp_b2_gen.c:64:
undefined reference to `uint32_array_to_c'
C:/msys/1.0/home/Administrator/stringencoders-v3.7.0/src/modp_b2_gen.c:66:
undefined reference to `uint32_array_to_c'
collect2: ld returned 1 exit status
make[1]: *** [modp_b2_gen] Error 1
make[1]: Leaving directory `/home/Administrator/stringencoders-v3.7.0'
make: *** [all] Error 2

Original issue reported on code.google.com by [email protected] on 5 Mar 2008 at 4:37

Attachments:

• config.log