The following test cases all result in a negative shift count (-1) in FillFractionals here

FastFixedDtoa( 2.10861548515811875e+15, 17, buffer, &length, &point );
FastFixedDtoa( 2.64452047982146350e+15, 17, buffer, &length, &point );
FastFixedDtoa( 3.82353004488187350e+15, 17, buffer, &length, &point );
FastFixedDtoa( 2.33131995055488594e+14, 17, buffer, &length, &point );
FastFixedDtoa( 1.91674615419831375e+15, 17, buffer, &length, &point );
FastFixedDtoa( 4.29987917825301050e+15, 17, buffer, &length, &point );
FastFixedDtoa( 8.57854524678346875e+14, 17, buffer, &length, &point );
FastFixedDtoa( 3.88706467562864350e+15, 17, buffer, &length, &point );
FastFixedDtoa( 1.54620738641213675e+15, 17, buffer, &length, &point );
FastFixedDtoa( 1.90564594624582575e+15, 17, buffer, &length, &point );
FastFixedDtoa( 1.47829189951993075e+15, 17, buffer, &length, &point );
FastFixedDtoa( 3.40787290971543450e+15, 17, buffer, &length, &point );

(When the test is performed, in all of these cases fractionals = 0 and point = 0.)

Checks when running "test-conversions", "test-ieee" and "test-strtod" fail, which is pretty much expected, since the fast floating-point behavior is deliberately imprecise.

See documentation here: https://msdn.microsoft.com/en-us/library/e7s85ffb.aspx

Should the library force "/fp:precise" behavior using the following pragma? Or shall it be up to the user to choose the correct floating-point behavior? In that case it would be good to add this to the documentation.

#pragma float_control(precise, on, push)
...
#pragma float_control(pop)

From http://code.google.com/p/double-conversion/issues/detail?id=30 :

-- sean.parent
Code inspection at: double-conversion.cc:44

Function level statics are not initialized in a thread safe manner with Visual Studio 2012 or prior. With gcc and clang thread safe initialization is optional (though required by C++11).

Could be fixed with any number of once init mechanisms, or aggregate initialization.

-- floitsch
I don't see any easy way of solving this without pulling in thread-specific headers.
I would rather just require -std=c++0x which, afaik, guarantees correct initialization.
I will discuss this with my colleagues next week and see if somebody comes up with a better solution.

-- stephen.mercer
If you simply move the function static out of the function and make it static to the file then it will be thread safe initialized. Reference this answer:
http://stackoverflow.com/questions/1962880/is-c-static-member-variable-initialization-thread-safe

So to make it thread safe, simply replace this code (and similar if you have other function-level statics):

const DoubleToStringConverter& DoubleToStringConverter::EcmaScriptConverter() {
   int flags = UNIQUE_ZERO | EMIT_POSITIVE_EXPONENT_SIGN;
   static DoubleToStringConverter converter(flags,
                                           "Infinity",
                                           "NaN",
                                           'e',
                                           -6, 21,
                                           6, 0);
  return converter;
}

with this code:

static DoubleToStringConverter kConverter(UNIQUE_ZERO | EMIT_POSITIVE_EXPONENT_SIGN,
                                          "Infinity",
                                          "NaN",
                                          'e',
                                          -6, 21,
                                          6, 0);

const DoubleToStringConverter& DoubleToStringConverter::EcmaScriptConverter() {
  return kConverter;
}

-- rafaelefernandez
You definitely do not want to move it out of the function because then you will run into the static initialization order problem.

Hi everyone!

we are trying to update the double-conversion conda package to v3.1.2* but it is raising an error in the tests.

[100%] Linking CXX executable cctest
[100%] Built target cctest
$SRC_DIR/test/cctest/test-conversions.cc:3611:
 CHECK_EQ(3.0, StrToD16("[email protected]", flags, 0.0, &processed, &all_used, char_separator, separator)) failed
#  Expected: 3.000000000000000000000000000000e+00
#  Found:    3.500000000000000000000000000000e+01
xargs: test/cctest/cctest: terminated by signal 6

any idea about what could be the problem? thanks!

• conda-forge/double-conversion-feedstock#8

I am trying to implement suggestion by @Neumann-A about properly using double-conversion in ITK. My attempt is here.

I cloned double-conversion into C:\Misc\double-conversion\ and built it using VS2017 in C:\Misc\double-conversion\vs2017\. If I point double-conversion_DIR during ITK configuration to C:\Misc\double-conversion\vs2017\generated I get CMake configure error:

CMake Error at C:/Misc/double-conversion/vs2017/generated/double-conversionConfig.cmake:27 (include):
  include could not find load file:

    C:/Misc/double-conversion/vs2017/generated/double-conversionTargets.cmake
Call Stack (most recent call first):
  Modules/ThirdParty/DoubleConversion/CMakeLists.txt:10 (find_package)

Rightfully so, because that folder only contains double-conversionConfig.cmake and double-conversionConfigVersion.cmake.

I then installed double-conversion into C:\Misc\double-conversion\install, and pointed ITK's double-conversion_DIR to C:\Misc\double-conversion\install\lib\cmake\double-conversion. This helped somewhat, but now the link library is not defined:

CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
ITKDoubleConversion_LIBRARIES
    linked by target "ITKCommon" in directory C:/Dev/ITK-git/Modules/Core/Common/src
    linked by target "ITKIOMeshVTK" in directory C:/Dev/ITK-git/Modules/IO/MeshVTK/src
    linked by target "ITKIOTransformInsightLegacy" in directory C:/Dev/ITK-git/Modules/IO/TransformInsightLegacy/src
    linked by target "ITKLabelVotingTestDriver" in directory C:/Dev/ITK-git/Modules/Segmentation/LabelVoting/test
    linked by target "ImageRegionIterator" in directory C:/Dev/ITK-git/Examples/Iterators
    linked by target "NeighborhoodIterators4" in directory C:/Dev/ITK-git/Examples/Iterators
...

Using a script to print all properties of a target, I get:

double-conversion::double-conversion ARCHIVE_OUTPUT_DIRECTORY = C:/Dev/ITK-2k17/lib
double-conversion::double-conversion AUTOGEN_ORIGIN_DEPENDS = ON
double-conversion::double-conversion AUTOMOC_COMPILER_PREDEFINES = ON
double-conversion::double-conversion AUTOMOC_MACRO_NAMES = Q_OBJECT;Q_GADGET;Q_NAMESPACE
double-conversion::double-conversion BINARY_DIR = C:/Dev/ITK-2k17/Modules/ThirdParty/DoubleConversion
double-conversion::double-conversion BUILD_WITH_INSTALL_RPATH = OFF
double-conversion::double-conversion CXX_EXTENSIONS = OFF
double-conversion::double-conversion CXX_STANDARD = 11
double-conversion::double-conversion CXX_STANDARD_REQUIRED = ON
double-conversion::double-conversion DEBUG_POSTFIX = 
double-conversion::double-conversion IMPORTED = TRUE
double-conversion::double-conversion IMPORTED_CONFIGURATIONS = DEBUG;RELWITHDEBINFO
double-conversion::double-conversion IMPORTED_GLOBAL = FALSE
double-conversion::double-conversion INSTALL_RPATH = 
double-conversion::double-conversion INSTALL_RPATH_USE_LINK_PATH = OFF
double-conversion::double-conversion INTERFACE_INCLUDE_DIRECTORIES = C:/Misc/double-conversion/install/include
double-conversion::double-conversion LIBRARY_OUTPUT_DIRECTORY = C:/Dev/ITK-2k17/lib
double-conversion::double-conversion NAME = double-conversion::double-conversion
double-conversion::double-conversion POSITION_INDEPENDENT_CODE = ON
double-conversion::double-conversion RUNTIME_OUTPUT_DIRECTORY = C:/Dev/ITK-2k17/bin
double-conversion::double-conversion SKIP_BUILD_RPATH = OFF
double-conversion::double-conversion SOURCE_DIR = C:/Dev/ITK-git/Modules/ThirdParty/DoubleConversion
double-conversion::double-conversion TYPE = STATIC_LIBRARY

INTERFACE_INCLUDE_DIRECTORIES is correct, but there is no property which points to the library to be linked.

Do you have a suggestion about how to solve this problem?

Side question: why don't you support building against build tree? In install tree either debug or release version of the library can be used, which means the other configuration fails to link in Visual Studio, due to:

double-conversion.lib(double-conversion.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in tester.obj
double-conversion.lib(double-conversion.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MDd_DynamicDebug' in tester.obj

Doing a checkout at 0e47d5a in January works, however top of tree reports the following, and it is not possible to build with the current cmake scripts.

CMake Error at CMakeLists.txt:44 (install):
install TARGETS given no ARCHIVE DESTINATION for static library target
"double-conversion".

CMake Warning (dev) in CMakeLists.txt:
No cmake_minimum_required command is present. A line of code such as

cmake_minimum_required(VERSION 3.4)

should be added at the top of the file. The version specified may be lower
if you wish to support older CMake versions for this project. For more
information run "cmake --help-policy CMP0000".
This warning is for project developers. Use -Wno-dev to suppress it.

-- Configuring incomplete, errors occurred!

I know this library originated from V8 so JavaScript is the primary client, but it would be nice to support parsing of hex-float literals as allowed in modern C++ as well (http://en.cppreference.com/w/cpp/language/floating_literal).

Thank you for making double-conversion!

Though it has a very unintuitive interface, the "standard" strtod/strtof can detect the following errors:

fprintf(stderr, "%s: not a decimal number\n", buff);
fprintf(stderr, "%s: extra characters at end of input: %s\n", buff, end);
fprintf(stderr, "%s out of range of type double/float\n", buff);

How can I accomplish the same thing with StringToDoubleConverter ?

How can I detect all of those error cases (ideally separately, but how can I even detect that one of them has happened regardless of which one) while also using the "nan"/"inf" parsing feature?

It seems I can detect "extra characters" with

processed_characters_count < length

But what about overflow and other malformed string errors?

If I set junk_string_value/empty_string_value to NaN then I lose the useful feature of the routine by which it detects the "nan" string (I cannot tell if the string is a well-formed "nan" or whether the string contains malformed content that got mapped to junk_string_value/empty_string_value==NaN).

Is there a way to do this currently? If so, please add it to the dox in double-conversion.h. If not, can we add it?

Thanks

What do you think about case insensibility for special values infinity and NaN?
Performance penalty not particularly noticeable in my tests.

The problem lies in DigitGenCounted (in fast-dtoa.cc):
If the fraction is 0 after the first iteration generating the integrals, then the second iteration will be skipped, and less than the requested number of digits (will typically) have been generated, resulting in the method return false, which then leads to a fallback to bignum based conversion.

It's trivial to add a check for the fraction being exactly zero after the first iteration, and then padding with 0 up to the requested number of digits.

What I however can't (yet) answer with 100% certainty is whether this could generate wrong results for some input? (I don't really think so).

The performance issue is seen e.g. for any number in form N*10^M

The routine from bignum-dtoa.cc:

    static void FixupMultiply10(int estimated_power, bool is_even,
                                int* decimal_point,
                                Bignum* numerator, Bignum* denominator,
                                Bignum* delta_minus, Bignum* delta_plus) {
      bool in_range;
      if (is_even) {
        // For IEEE doubles half-way cases (in decimal system numbers ending with 5)
        // are rounded to the closest floating-point number with even significand.
        in_range = Bignum::PlusCompare(*numerator, *delta_plus, *denominator) >= 0;
      } else {
        in_range = Bignum::PlusCompare(*numerator, *delta_plus, *denominator) > 0;
      }
      if (in_range) {
        // Since numerator + delta_plus >= denominator we already have
        // 1 <= numerator/denominator < 10. Simply update the estimated_power.
        *decimal_point = estimated_power + 1;
      } else {
        *decimal_point = estimated_power;
        numerator->Times10();
        if (Bignum::Equal(*delta_minus, *delta_plus)) {
          delta_minus->Times10();
          delta_plus->AssignBignum(*delta_minus);
        } else {
          delta_minus->Times10();
          delta_plus->Times10();
        }
      }
    }

Why do you add delta_plus to numerator and then compare the sum to denominator ? Do we really need delta_plus here ? Can we just write (and forget is_even as well):

in_range = Bignum::Compare(*numerator, *denominator) >= 0;

It works fine for BignumDtoaGayShortest test, too.

According to my understanding the numerator must greater than or equal to denominator here, so that no leading 0 digit will be produced by GenerateShortestDigits.

$ cmake -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DLIB_SUFFIX=64 ..
[...]
CMake Warning:
  Manually-specified variables were not used by the project:

    LIB_INSTALL_DIR
    LIB_SUFFIX
$ make
[...]
$ make -s install
[100%] Built target double-conversion
Install the project...
-- Install configuration: ""
CMake Error at cmake_install.cmake:41 (file):
  file cannot create directory: /usr/local/lib.  Maybe need administrative
  privileges.

The lib dir /usr/local/lib is wrong. It should be lib64.

The last tagged release is dated from 2014 and quite a few fixes have landed in the code base since then. Would you guys consider tagging a new release with the appropriate version bump?

Cheers,

I'm neeewb how the shit does this work

Erlang-jiffy keeps a local copy of this double-conversion library and its build is failing in Debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764500
Erlang-jiffy's author would not like to implement the support in erlang-jiffy only diverging from this codebase:
davisp/jiffy#74

This is a little test I appended to TEST(DoubleToShortest)

for (int i = 0; i <= 100; ++i) {
    char buffer[10];
    builder.Reset();
    CHECK(dc.ToShortest(i*0.1, &builder));
    if (i % 10 == 0) {
        sprintf(buffer, "%d", i/10);
        CHECK_EQ(buffer, builder.Finalize());
    } else {
        sprintf(buffer, "%d.%d", (i/10), (i%10));
        CHECK_EQ(buffer, builder.Finalize());
    }
  }

And the first failure is:

 CHECK_EQ(buffer, builder.Finalize()) failed
#  Expected: 0.3
#  Found:    0.30000000000000004

I realize that 3*0.1 != 0.3 due to floating point limitations, but for my purposes its close enough that I wish I had some way to tell ToShortest to truncate it.

all double-conversion headers should be correctly included with "" instead of <>

example:
#include <double-conversion\utils.h>
should be changed to
#include "utils.h"

you are generating build failures due to that using cmake....
also system includes are not meant to be used for internal headers... also your are vulnerable to including the wrong utils.h using system headers.
Example:
Two folders:
double-conversion
double-conversion_v2

double-conversion_v2 will include the headers from double-conversion instead of double-conversion_v2

In utils.h, DOUBLE_CONVERSION_CORRECT_DOUBLE_OPERATIONS is set to 1 only for architectures known to work correctly (and it's unset for architectures known not to support). For unknown architectures, a compile time error is emitted with #error pragma.

PNaCl (portable native client) is taken to '#error' branch. This was discovered when compiling ICU 61 for Chromium (ICU 61 does have a version of double-conversion library).

#elif defined(__pnacl__) || defined(__native_client__)
#undef DOUBLE_CONVERSION_CORRECT_DOUBLE_OPERATIONS
#else // final #else
#error "Target ... not detected s supported by Double-Conversion
#endif 

Perhaps adding one more #elif branch for PNaCl (and NaCl) as above would work.

ICU bug : https://ssl.icu-project.org/trac/ticket/13750

When using double_conversion::DoubleToStringConverter::DoubleToAscii() with mode=PRECISION and requested_digits=6, I find that the input 5735285 generates digits 573529.

I believe it should be 573528 (with the last digit rounded even), as produced by David M. Gay's dtoa with mode 2.

The produced output 1.8011300000000001 is at least not what I would expect from ToShortest.

This code path doesn't generate a fallback to bignum calculations. I can't fully deduce from the comments whether this is intentionally.

But the net outcome is that this makes ToShortest a no go for our usage.

We have implemented an overlay of ToShortest that takes an additional max_digits input that we can use to solve the problem, but I'm wondering whether there is a better / more general solution.

When I tried to compile Chrome with ICU 61 (that includes this library) on Windows with clang in MSVC compatibility mode(?), I got a warning from clang about unused typedef. Because Chrome is built with 'treat error as warning' (-Werror), it leads to a compile failure. I can turn off the warning(-Wno-unused-local-typedef ) for ICU when building Chrome.

However, it'd be nice to support this toolchain.

// Compile time assertion: sizeof(Dest) == sizeof(Source)
// A compile error here means your Dest and Source have different sizes.
DOUBLE_CONVERSION_UNUSED
    typedef char VerifySizesAreEqual[sizeof(Dest) == sizeof(Source) ? 1 : -1];

Earlier in utils.h, DOUBLE_CONVERSION_UNUSED is defined as following:

#if defined(__GNUC__)
#define DOUBLE_CONVERSION_UNUSED __attribute__((unused))
#else
#define DOUBLE_CONVERSION_UNUSED
#endif

I guess clang on Windows (along with MSVC) would not have GNUC defined and DOUBLE_CONVERSION_UNSED becomes empty. OTOH, clang on Linux/Mac has GNUC defined.

scons adds -fPIC but cmake does not.

Adding this to double-conversion/src/CMakeLists.txt solved my problem:

if (CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64")
  set_target_properties(double-conversion PROPERTIES COMPILE_FLAGS "-fPIC")
endif()

Hi everyone!

I am packaging double-conversion using conda-build (conda-forge/staged-recipes#5770)

I need to add a very small test file to check if double-conversion is installed properly.

Could you point me a very simple test file and an example about how could I use it?

My best regards,

Hi everyone,

I packaged double-conversion using conda-build but it seems I am missing something.

conda package is a pre-built package, so when I install the conda package in my machine, it just save binary files and some extra files to my conda environment.

After installed double-conversion (with conda) I am trying to build facebook/folly and it raises this error:

checking for ceil in -ldouble-conversion... no
configure: error: Please install double-conversion library

on folly I found this references on build step:

• https://github.com/facebook/folly/blob/master/CMake/folly-deps.cmake#L20
• https://github.com/facebook/folly/blob/master/CMake/FindDoubleConversion.cmake

maybe my conda-build log could help:

source tree in: /opt/miniconda/conda-bld/folly_1526340035536/work
INFO: activate-binutils_linux-64.sh made the following environmental changes:
+ADDR2LINE=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-addr2line
+AR=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-ar
+AS=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-as
+CXXFILT=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-c++filt
+ELFEDIT=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-elfedit
+GPROF=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gprof
+HOST=x86_64-conda_cos6-linux-gnu
+LD=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-ld
+LD_GOLD=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-ld.gold
+NM=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-nm
+OBJCOPY=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-objcopy
+OBJDUMP=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-objdump
+RANLIB=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-ranlib
+READELF=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-readelf
+SIZE=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-size
+STRINGS=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-strings
+STRIP=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-strip
INFO: activate-gcc_linux-64.sh made the following environmental changes:
+CC=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-cc
+CFLAGS=-march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -pipe -I/opt/miniconda/conda-bld/folly_1526340035536/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_pla/include -fdebug-prefix-map=${SRC_DIR}=/usr/local/src/conda/${PKG_NAME}-${PKG_VERSION} -fdebug-prefix-map=${PREFIX}=/usr/local/src/conda-prefix
+CPP=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-cpp
+CPPFLAGS=-DNDEBUG -D_FORTIFY_SOURCE=2 -O2
+DEBUG_CFLAGS=-march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-all -fno-plt -Og -g -Wall -Wextra -fvar-tracking-assignments -pipe -I/opt/miniconda/conda-bld/folly_1526340035536/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_pla/include -fdebug-prefix-map=${SRC_DIR}=/usr/local/src/conda/${PKG_NAME}-${PKG_VERSION} -fdebug-prefix-map=${PREFIX}=/usr/local/src/conda-prefix
+DEBUG_CPPFLAGS=-D_DEBUG -D_FORTIFY_SOURCE=2 -Og
+GCC=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc
+GCC_AR=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc-ar
+GCC_NM=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc-nm
+GCC_RANLIB=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc-ranlib
+LDFLAGS=-Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -Wl,-rpath,/opt/miniconda/conda-bld/folly_1526340035536/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_pla/lib -L/opt/miniconda/conda-bld/folly_1526340035536/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_pla/lib
+_CONDA_PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata_x86_64_conda_cos6_linux_gnu
INFO: activate-gxx_linux-64.sh made the following environmental changes:
+CXX=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-c++
+DEBUG_CXXFLAGS=-fvisibility-inlines-hidden -std=c++17 -fmessage-length=0 -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-all -fno-plt -Og -g -Wall -Wextra -fvar-tracking-assignments -pipe -I/opt/miniconda/conda-bld/folly_1526340035536/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_pla/include -fdebug-prefix-map=${SRC_DIR}=/usr/local/src/conda/${PKG_NAME}-${PKG_VERSION} -fdebug-prefix-map=${PREFIX}=/usr/local/src/conda-prefix
+GXX=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-g++
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
autoreconf: configure.ac: tracing
autoreconf: configure.ac: creating directory build-aux
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build-aux'.
libtoolize: copying file 'build-aux/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
autoreconf: running: /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/autoconf --force
autoreconf: running: /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:32: installing 'build-aux/compile'
configure.ac:32: installing 'build-aux/config.guess'
configure.ac:32: installing 'build-aux/config.sub'
configure.ac:27: installing 'build-aux/install-sh'
configure.ac:27: installing 'build-aux/missing'
Makefile.am: installing 'build-aux/depcomp'
parallel-tests: installing 'build-aux/test-driver'
autoreconf: Leaving directory `.'
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking how to print strings... printf
checking for style of include used by make... GNU
checking for gcc... /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc accepts -g... yes
checking for /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc option to accept ISO C89... none needed
checking whether /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc understands -c and -o together... yes
checking dependency style of /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc... gcc3
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc... /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-ld
checking if the linker (/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-nm
checking the name lister (/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-nm) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking how to convert x86_64-pc-linux-gnu file names to x86_64-pc-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-pc-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-ld option to reload object files... -r
checking for objdump... /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for archiver @FILE support... @
checking for strip... /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-strip
checking for ranlib... /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-ranlib
checking command to parse /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-nm output from /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc object... ok
checking for sysroot... no
checking for a working dd... /usr/bin/dd
checking how to truncate binary pipes... /usr/bin/dd bs=4096 count=1
checking for mt... no
checking if : is a manifest tool... no
checking how to run the C preprocessor... /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-cpp
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc supports -fno-rtti -fno-exceptions... no
checking for /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc option to produce PIC... -fPIC -DPIC
checking if /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc PIC flag -fPIC -DPIC works... yes
checking if /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc static flag -static works... yes
checking if /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc supports -c -o file.o... yes
checking if /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc supports -c -o file.o... (cached) yes
checking whether the /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc linker (/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking how to run the C++ preprocessor... g++ -E
checking for ld used by g++... /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-ld -m elf_x86_64
checking if the linker (/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-ld -m elf_x86_64) is GNU ld... yes
checking whether the g++ linker (/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-ld -m elf_x86_64) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC -DPIC
checking if g++ PIC flag -fPIC -DPIC works... yes
checking if g++ static flag -static works... no
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... (cached) GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking for gcc... (cached) /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc accepts -g... (cached) yes
checking for /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc option to accept ISO C89... (cached) none needed
checking whether /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc understands -c and -o together... (cached) yes
checking dependency style of /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc... (cached) gcc3
checking if g++ supports C++1y features without additional flags... yes
checking if g++ supports C++1y features with -std=c++1y... yes
checking if g++ supports C++1y features with -std=gnu++1y... yes
checking whether -Wshadow-local and -Wshadow-compatible-local are supported... yes
checking for main in -lgflags... yes
checking for gflags viability... yes
checking for pkg-config... /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for gflags... yes
checking for main in -lglog... yes
checking for glog viability... yes
checking for libglog... yes
configure: WARNING: "Using existing OpenSSL flags from environment."
checking for openssl... yes
checking for boostlib >= 1.51.0... yes
checking whether the Boost::Context library is available... yes
checking for exit in -lboost_context-mt... yes
checking whether the Boost::Program_Options library is available... yes
checking for exit in -lboost_program_options-mt... yes
checking whether the Boost::Thread library is available... yes
checking for exit in -lboost_thread... yes
checking whether the Boost::Regex library is available... yes
checking for exit in -lboost_regex-mt... yes
checking whether the Boost::System library is available... yes
checking for exit in -lboost_system... yes
checking whether the Boost::Filesystem library is available... yes
checking for exit in -lboost_filesystem... yes
checking whether the Boost::Chrono library is available... yes
checking for exit in -lboost_chrono-mt... yes
checking for python... /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/python
checking for python version... 3.6
checking for python platform... linux
checking for python script directory... ${prefix}/lib/python3.6/site-packages
checking for python extension module directory... ${exec_prefix}/lib/python3.6/site-packages
checking for ANSI C header files... (cached) yes
checking features.h usability... yes
checking features.h presence... yes
checking for features.h... yes
checking malloc.h usability... yes
checking malloc.h presence... yes
checking for malloc.h... yes
checking bits/functexcept.h usability... yes
checking bits/functexcept.h presence... yes
checking for bits/functexcept.h... yes
checking bits/c++config.h usability... yes
checking bits/c++config.h presence... yes
checking for bits/c++config.h... yes
checking double-conversion/double-conversion.h usability... yes
checking double-conversion/double-conversion.h presence... yes
checking for double-conversion/double-conversion.h... yes
checking for ceil in -ldouble-conversion... no
configure: error: Please install double-conversion library

this is my build script: https://github.com/conda-forge/double-conversion-feedstock/blob/master/recipe/build.sh

this is my build requirements: https://github.com/conda-forge/double-conversion-feedstock/blob/master/recipe/meta.yaml#L20

Any help will be very appreciated. Thanks.

On Fedora, 64-libraries need to get installed into /usr/lib64.

Right now I'm developing a C library for a system called CloudABI (more details: https://github.com/NuxiNL/cloudlibc). As this double-conversion code is supposed to be faster than David M. Gay's gdtoa implementation (and also a lot more readable), my intent is to use this code to implement strto{f,d,ld}() and printf()'s %f. So far things are going all right. strtof() and strtod() already work as expected. My next task is getting printf() to work.

It looks like double-conversion only supports float and double. This is a bit problematic, as strtold() and printf()'s %Lf are supposed to parse and print floating point numbers with larger precision. Are there any plans to add 80/128-bit long double support to double-conversion?

Thanks!

This assertion in bignum.cc in DivideModuloIntBignum fails for the two bignums A = 0x11100000 and B = 100000. But A/B = 0x111 and as I understand it the function should be able two handle these inputs.

Now, I don't understand the intent of this assertion. It seems to check that the leading bigit of other is >= 2^(28-4) which indicates that other should be some kind of normalized...? Just commenting it out, the function produces the correct results... so, is the assertion correct here?

FWIW, there are other numbers for which the assertion fails, which came up while trying to speed up GenerateCountedDigits in bignum-dtoa.cc: https://github.com/effzeh/double-conversion/commit/57a09e673e57abe2fc78a8892da9cc8019d7c92a

clang give 2 warnings:

utils.h:166:10: warning: unused function template 'Max' [-Wunused-template]
static T Max(T a, T b) {
         ^
utils.h:173:10: warning: unused function template 'Min' [-Wunused-template]
static T Min(T a, T b) {
         ^

I suspect it has to do with the 'static' declaration...

Hello,

Do you know about Conan?

Conan is modern dependency manager for C++. And will be great if your library will be available via package manager for other developers.

Now we have famous C++ projects, including Google Flatbuffers. We could support you writing a recipe and publishing your packages on Bintray.

If you have any questions, just ask :-)

Before submitting another insane PR I'd like to explain where I'm coming from, and where I'm headed for.

Back in November 2015, when we added this library to our JSON library for double-to-string and string-to-double conversions (because it was the only one that always got string-to-double right), we had to make one big change:

The creation of a header-only version of Strtod() (or rather, what is now StrtodTrimmed()) by basically copying Strtod() into an empty header file and adding everything it depends on (marking functions as inline as required) until it worked...

(The code is very "clean" in that it compiles with -std=c++17 -Wall -Werror -pedantic even on more modern compilers, kudos!)

Now, in order to allow for easier future updates of the double-conversion part in our JSON library, I wanted to see to which degree it was possible to close the gap between the current form, and the partial header-only form that we would require.

(Where "possible" is to be understood both in terms of technically possible, and in line with your development style and plans for the future.)

So what I'd like to do, if possible, is eliminate all *.cc files except for string-to-double.cc and double-to-string.cc by moving everything into the respective *.h files, making sure everything is marked as inline. Then some *.h files could be split up, e.g. by moving StringBuilder into a dedicated file etc. Finally the namespace could become a macro to make changing it easier.

Then we could simply copy strtod.h, and all other headers it depends on, and take it from there. Now we realise that's probably a rather non-standard use-case, which is why I wanted to check in first and see whether this would be ok with you...

Final note, in case you are wondering what the commits I have submitted so far have to do with creating a partial header-only version of this library, the answer is that I simply wanted to (re)acquaint myself a bit more with the code, and understanding enough to make some contributions (in the direction of more idiomatic "modern" C++, or some small simplifications) is one way I use to get to know a piece code.

Thank you for listening, hope I'm not taking too much of your time ;-)

The architecture detection in utils.h (starting on line 56) isn't comprehensive. The case that matters to me is that it looks for __ppc__ and __powerpc__, which are #defined by GCC, but not _ARCH_PPC or _ARCH_PPC64, which are #defined by IBM's XL C/C++ compilers (e.g., http://sourceforge.net/p/predef/wiki/Architectures/ ).

When I use reactnative Integration in an with Existing Apps. I get an error .

nstalling DoubleConversion (1.1.5)
[!] /bin/bash -c
set -e
mv src double-conversion

mv: rename src to double-conversion: No such file or directory

Buildroot is building Qt5 for a large number of architectures, and the build now fails on Microblaze and OpenRISC architecture because the copy of the double-conversion library in Qt5 doesn't have support for those architecture.

I am willing to test on those architectures what needs to be tested, but unfortunately the comment at https://github.com/google/double-conversion/blob/master/double-conversion/utils.h#L60 is not clear enough (to me) to know what to test.

Also, wouldn't it make sense for the code in utils.h to assume that DOUBLE_CONVERSION_CORRECT_DOUBLE_OPERATIONS is false for unsupported/unknown architectures ?

From http://code.google.com/p/double-conversion/issues/detail?id=51 :
When I tried to use double-conversion with hhvm building process, I was required to manually copy *.h files to respected folders. Otherwise hhvm build was unable to locate them.

Another issue not strictly related to JavaScript, would be nice to see support for a configurable separator character. It's ok if it's a single character, this way numbers like 1_000_000 and 1'000'000 could be parsed without having to pre-process them.

@abrodkin filed this against ICU's import of double-conversion:

• https://unicode-org.atlassian.net/browse/ICU-20155

and an associated PR:

• unicode-org/icu#149

From http://code.google.com/p/double-conversion/issues/detail?id=36 :

When the FPU control word or _MM_SET_FLUSH_ZERO_MODE is toggled the algorithm doesn't work.

-- stephen.mercer
Can you go into more detail about the severity of this? If we were to use your code in our application, when would this occur? What could we do to prevent it? And when the algorithm doesn't work, does that mean your strings are junk or are they just not the shortest strings?

-- floitsch
_MM_SET_FLUSH_ZERO_MODE is used to flush denormals to 0 (see http://en.wikipedia.org/wiki/Denormal_number).

Quoting Arash Partow (author of http://www.codeproject.com/Articles/23198/C-String-Toolkit-StrTk-Tokenizer):
"But in short both the atod and dtoa functionalities of [the double-conversion] library have issues with double and float types when values approach denormalized but are not denormalized, there is inconsistent behavior from what is expected when the FPU control word or _MM_SET_FLUSH_ZERO_MODE is toggled - both from a performance and precision standpoint."

If you don't modify the __MM_SET_FLUSH_ZERO_MODE flag, or if you don't care about numbers with an absolute value <= 2.2250738585072009 × 10^−308 (or close to it), you should be fine.

I've noticed a fairly large class of numbers for which double-conversion is slow to produce the shortest decimal representation. Here's a test case:

#include "double-conversion.h"
using namespace double_conversion;

int main()
{
    size_t i = 0;
    for (int j = 0; j < 5e6; j++)
    {
#ifdef FAST
        double d = (rand() % 1000000) / 100000.0; // 10^5
#else
        double d = (rand() % 1000000) / 131072.0; // 2^17
#endif
        char buf[20];
        bool s;
        int length, decpt;
        DoubleToStringConverter::DoubleToAscii(d, DoubleToStringConverter::SHORTEST, 0, buf, sizeof buf, &s, &length, &decpt);
        i += strlen(buf);
    }
    return i % 1000;
}

On my machine (Ubuntu 15.10, Haswell CPU) I get:

$ g++ -O3 *.cc -o foo -DFAST && time ./foo
real    0m0.446s
user    0m0.444s
sys 0m0.000s
$ g++ -O3 *.cc -o foo && time ./foo
real    0m2.402s
user    0m2.400s
sys 0m0.000s

So for random integers divided by 2^17 it's running 6x slower than for some other random inputs. Profiling shows that this is because FastDtoa() is usually (always?) failing, so it has to fall back to BignumDtoa(). Is this expected? Is there a way to make FastDtoa() cope with more cases?

Incidentally, I noticed this when benchmarking our software (which now uses double-conversion) against a previous version that used David Gay's dtoa(), using his mode 4 to get the shortest representation but limited to 10 digits. double-conversion doesn't seem to have an equivalent of mode 4, so we're forced to use SHORTEST mode, which makes double-conversion appear slower than dtoa() on random integers / 2^17.

Update README file to also include info on how to build with using Bazel @mzhaom? Thanks!

TEST(FooBar)
{
    double f = 1.7976931348623157e308;

    const int kBufferSize = 128;

    char buffer[kBufferSize];

    StringBuilder builder(buffer, kBufferSize);

    DoubleToStringConverter dc(0, NULL, NULL, 'e', -4, 17, 0, 0);

    dc.ToExponential(f, 14, &builder);

    const char* str = builder.Finalize();

    StringToDoubleConverter sc(0, 0.0, 1.0, "inf", "nan");

    int count;

    double f2 = sc.StringToDouble(str, strlen(str), &count);

    CHECK(fabs(f - f2) < 1000.0);
}

This may be extreme. When requested_digits is 14, the max value of double 1.7976931348623157e308 is rounded-up to "1.79769313486232e308"; If you read this string back to double, you will get an inf value.

You can use define _M_ARM for that

See microsoft/vcpkg#1167

I tested the routines on Win10 VS2017 against my strtod test battery and all conversion tests passed. This is a very good sign!

Nevertheless some formatting tests failed due to the fact multiple styles for inf & nan literals aren't supported, e.g. excepting both 'inf' & 'infinity' just as Python does.

It would be nice to be able to construct StringToDoubleConverter which is able to interpret multiple style as described in C99 standard section 7.19.6.1.8.

Maybe one way to do this is to be able to use regex for StringToDoubleConverter infinity_symbol & nan_symbol.

C:\src\vcpkg\installed\x64-windows\include\double-conversion\double-conversion.h(31): fatal error C1083: Cannot open include file: 'double-conversion/utils.h': No such file or directory is the error encountered. More information can be found in vcpkg's issue.

line 456: ~((static_cast<uint64_t>(1) << (64 - bit_size)) - 1);
Is undefined behavior, since 64-bit_size could be negative.

From http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/n4594.pdf:
The value of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are zero-filled. If E1 has an unsigned
type, the value of the result is E1 × 2
E2, reduced modulo one more than the maximum value representable in
the result type. Otherwise, if E1 has a signed type and non-negative value, and E1 × 2
E2 is representable
in the corresponding unsigned type of the result type, then that value, converted to the result type, is the
resulting value; otherwise, the behavior is undefined.
3 The value of E1 >> E2 is E1 right-shifted E2 bit positive

https://github.com/ulfjack/ryu
https://www.reddit.com/r/programming/comments/92dncd/ry%C5%AB_fast_floattostring_conversion/

On my laptop I quickly measured Ryū to almost be 4X faster than double-conversion.

The implementation in the GitHub repository above lacks the output format flexibility offered by double-conversion, so that would need to be addressed.

This is a faster and complete way to do double conversation.

http://cseweb.ucsd.edu/~lerner/papers/fp-printing-popl16.pdf

I was wondering whether you'd accept a PR that adds a new function corresponding to exactly what we've been using for quite a while now from our slightly hacked copy of the double-conversion library, namely a Strtod() that starts with double guess, i.e. skips all the trimming and stuff (that we don't need because the PEGTL grammar in our JSON library implicitly ensures that no leading zeros etc. are passed to our Strtod()).

In other words this would split Strtod() into two functions, keeping the current name with the current functionality. Of course then the big question would be how to name the "back-end" function that starts with double guess, would StrtodMain() or StrtodImpl() be acceptable?

This indicates a binary-incompatible change, but there doesn't seem to be the need for one. It seems to me that commit e13e72e incorrectly changed the way the soname is created (which wasn't being done properly in 2.0 either, but that's another story).

The template type Iterator is used throughout double-conversion.cpp. It appears that Iterator can be one of two types:

• const uc16*
• const char*

There is a function Advance whose signature is:

template<class Iterator>
static bool Advance (Iterator* it, char separator, int base, Iterator& end)

The call sites look like this:

// current is of type Iterator
Advance(&current, separator_, 10, end)

The problem is that separator_ is being downcast to a char even when using the uc16* template type for the string. The implication is that there is a possible loss of information; for example, the separator might be a Unicode code point that doesn't fit in a char. A great real-life example could be 'NARROW NO-BREAK SPACE' (U+202F), which is now used in CLDR as the default grouping separator in France.

The code should be checked to ensure that separator_ is not downcast to a char unless the iterator is a char iterator.