Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

std::uint64_t numbers above a certain value are not formatted correctly #235

Open
fedmos opened this issue Aug 7, 2024 · 1 comment · May be fixed by #246
Open

std::uint64_t numbers above a certain value are not formatted correctly #235

fedmos opened this issue Aug 7, 2024 · 1 comment · May be fixed by #246

Comments

@fedmos
Copy link

fedmos commented Aug 7, 2024

Boost version: 1.83.000
Compiler : GCC 13.2.0

std::uint64_t numbers above a certain value are not formatted correctly:
in the following minimal example first is formatted correctly (commas are used as separators), while second is not correctly formatted (no commas are used)

Example:

#include <iostream>
#include <iomanip>
#include <boost/format.hpp>
#include <boost/locale.hpp>

int main()
{
    boost::locale::generator gen;
    gen.categories(boost::locale::category_t::convert | boost::locale::category_t::formatting);
    auto locale = gen.generate("en_US.utf-8");
    
    std::stringstream output;
    output << boost::locale::as::number;
    output << std::setprecision(6);
    output.imbue(locale);
    
    std::uint64_t first = 9223372036854U;
    std::uint64_t second = 9223372036854775808U;
    
    output << first << " " << second;
    std::clog << output.str() << std::endl;
    return 0;
}

Console output:

9,223,372,036,854 9223372036854775808

Flamefire added a commit that referenced this issue Aug 8, 2024
As reported in #235 formatting the first number which doesn't fit into
int64_t anymore fails to add the thousands separators.
I.e.:
`9223372036854775807` -> `9,223,372,036,854,775,807`
`9223372036854775808` -> `9223372036854775808`

Add a test reproducing that that for all backends.
Flamefire added a commit that referenced this issue Aug 8, 2024
As reported in #235 formatting the first number which doesn't fit into
int64_t anymore fails to add the thousands separators.
I.e.:
`9223372036854775807` -> `9,223,372,036,854,775,807`
`9223372036854775808` -> `9223372036854775808`

Add a test reproducing that that for all backends.
@Flamefire
Copy link
Collaborator

The problem is that ICU only supports formatting int64_t numbers

So any integer value above INT32_MAX will be formatted using the classic locale. This is in line with how Boost.Locale handles things in general: Do the best it can and gracefully fall back to less functionality. In this case it is using the classic format.

I'm working on a solution

Flamefire added a commit that referenced this issue Dec 5, 2024
As reported in #235 formatting the first number which doesn't fit into
int64_t anymore fails to add the thousands separators.
I.e.:
`9223372036854775807` -> `9,223,372,036,854,775,807`
`9223372036854775808` -> `9223372036854775808`

Add a test reproducing that that for all backends.
Flamefire added a commit that referenced this issue Dec 5, 2024
ICU doesn't support uint64_t directly but provides access to formatting
and parsing of decimal number strings.
Use Boost.Charconv to interface with that.

Fixes #235
@Flamefire Flamefire linked a pull request Dec 5, 2024 that will close this issue
Flamefire added a commit that referenced this issue Dec 30, 2024
As reported in #235 formatting the first number which doesn't fit into
int64_t anymore fails to add the thousands separators.
I.e.:
`9223372036854775807` -> `9,223,372,036,854,775,807`
`9223372036854775808` -> `9223372036854775808`

Add a test reproducing that that for all backends.
Flamefire added a commit that referenced this issue Dec 30, 2024
ICU doesn't support uint64_t directly but provides access to formatting
and parsing of decimal number strings.
Use Boost.Charconv to interface with that.

Fixes #235
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants