On Mon, Nov 12, 2018 at 5:54 PM Gavin Lambert via Boost-users <boost-users@lists.boost.org> wrote:
On 13/11/2018 11:47, Michael Powell wrote:
Hex and octal literals produce unsigned values. You need to put those into a uintmax_t, not an intmax_t.
FWIW, you can still use an intmax_t in your AST if you want, as the automatic attribute conversion will permit the twos-complement conversion (though it might annoy some sanitisers).
hex_val %= no_case["0x"] >> uint_parser<std::uintmax_t, 16>{}; oct_val %= "0" >> uint_parser<std::uintmax_t, 8>{}; dec_val %= int_parser<ast::int_t, 10>{};
Hmm, I see... Maybe this is rinsing out in the conversion wash, then, because the decimal phrase seems to handle negative values just fine, whereas the hex and octal parsers fall flag on their face.
Decimal values can be negative. Octal and hex values can't.
Right, I understand that. However, ultimately when the AST is synthesized, I do not care whether numeric literals were hex, octal, decimal, or some other indeterminate radix. The sign applies to whatever that result is, at least according to the language spec I am working with.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users