Re: [Boost-users] [Spirit] Qi int_parser rejecting a negative signed std::intmax_t

Subject: Re: [Boost-users] [Spirit] Qi int_parser rejecting a negative signed std::intmax_t
From: Michael Powell (mwpowellhtx_at_[hidden])
Date: 2018-11-12 22:57:17

On Mon, Nov 12, 2018 at 5:54 PM Gavin Lambert via Boost-users
<boost-users_at_[hidden]> 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_at_[hidden]
> https://lists.boost.org/mailman/listinfo.cgi/boost-users