[
https://issues.apache.org/jira/browse/MESOS-8484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16338220#comment-16338220
]
Benno Evers commented on MESOS-8484:
------------------------------------
In boost 1.53, lexical_cast implements its own parser that doesnt handle the
'0x' prefix, therefore parsing the two strings in the test would return an
error.
In boost 1.65, lexical_cast calls std::istream::operator>>, which on mac (i.e.
using libc++) can successfully parse strings of the form "0x10.9" or "0x1p-5",
and returns the correct number. On linux platforms (i.e. using libstdc++),
std::istream::operator>> is not able to parse these strings and thus returns an
error.
The function stout::numify wants to achieve platform independence by forbidding
these kinds of literals on all platforms. However, the checks are only
happening *after* boost was already given the chance to parse the string, which
has platform-dependent behaviour.
> stout test NumifyTest.HexNumberTest fails.
> -------------------------------------------
>
> Key: MESOS-8484
> URL: https://issues.apache.org/jira/browse/MESOS-8484
> Project: Mesos
> Issue Type: Bug
> Affects Versions: 1.6.0
> Environment: macOS 10.13.2 (17C88)
> Apple LLVM version 9.0.0 (clang-900.0.37)
> ../configure && make check -j6
> Reporter: Till Toenshoff
> Assignee: Benjamin Bannier
> Priority: Blocker
>
> The current Mesos master shows the following on my machine:
> {noformat}
> [ RUN ] NumifyTest.HexNumberTest
> ../../../3rdparty/stout/tests/numify_tests.cpp:57: Failure
> Value of: numify<double>("0x10.9").isError()
> Actual: false
> Expected: true
> ../../../3rdparty/stout/tests/numify_tests.cpp:58: Failure
> Value of: numify<double>("0x1p-5").isError()
> Actual: false
> Expected: true
> [ FAILED ] NumifyTest.HexNumberTest (0 ms)
> {noformat}
> This problem disappears for me when reverting the latest boost upgrade.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
