Feature request - attribute type should not be altered for terminal rules

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Feature request - attribute type should not be altered for terminal rules

Vitaly Budovski-4
Hi all,

I've discussed this with Joel on IRC, but am posting this to the list
so others can comment.
Currently code such as this results in unexpected behaviour (for me).

#define BOOST_SPIRIT_ACTIONS_ALLOW_ATTR_COMPAT

int result;
parse(first, last, word[_val = if_else_(_1 > 1000u, -1, 5)], result);

This results in a warning about comparison between signed and unsigned
types (_1 > 1000u).
This is because the attribute type is converted to int to match the
type of the result variable, even though the type returned by word is
unsigned.

I would like to request a change in the behaviour for terminal rules,
if possible, so that this no-longer occurs. The type of _1 would now
be unsigned, and the comparison would happen without warnings. The two
possible branches output a type that is compatible with the type of
the output variable and so it succeeds.

The code below, however, should result in a warning or error:

int result;
parse(first, last, dword, result); // Difference in sign

or

unsigned result;
parse(first, last, qword, result); // Might overflow

Is this feasible?


Regards,

Vitaly

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Spirit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Feature request - attribute type should not be altered for terminal rules

Joel de Guzman-2
On 5/10/2012 3:00 PM, Vitaly Budovski wrote:

> Hi all,
>
> I've discussed this with Joel on IRC, but am posting this to the list
> so others can comment.
> Currently code such as this results in unexpected behaviour (for me).
>
> #define BOOST_SPIRIT_ACTIONS_ALLOW_ATTR_COMPAT
>
> int result;
> parse(first, last, word[_val = if_else_(_1 > 1000u, -1, 5)], result);
>
> This results in a warning about comparison between signed and unsigned
> types (_1 > 1000u).
> This is because the attribute type is converted to int to match the
> type of the result variable, even though the type returned by word is
> unsigned.
>
> I would like to request a change in the behaviour for terminal rules,
> if possible, so that this no-longer occurs. The type of _1 would now
> be unsigned, and the comparison would happen without warnings. The two
> possible branches output a type that is compatible with the type of
> the output variable and so it succeeds.
>
> The code below, however, should result in a warning or error:
>
> int result;
> parse(first, last, dword, result); // Difference in sign
>
> or
>
> unsigned result;
> parse(first, last, qword, result); // Might overflow
>
> Is this feasible?

I probably did not communicate well on IRC. Let me try again.
So, what is the attribute of the int_ parser? By default, it is
int. However, if the user passes in his own attribute, the int_
parser uses its type and it becomes its attribute. Basically, for
any parser P, we have:

  1) DA: the default attribute type of P (for int_ it is int)
  2) AA: The actual attribute of P (the one that the user actually provides)

Essentially, P is not tied to its DD (default attribute type). For as long as
AA (The actual attribute) is 'compatible with' the parser P. It will be
accepted. For example, your AA can be short for parser int_. That is OK.
int_ will try to parse as much as it can, but report an error when the
short overflows. For that matter, it should also be possible to pass in
user defined types such as bignum for int_. When passed a bignum, the int_
parser will use it, parse the input, and compute the result (compile the
bignum).

Semantic actions use the AA attribute when you #define
BOOST_SPIRIT_ACTIONS_ALLOW_ATTR_COMPAT. That way, if you pass in a
bignum, your SA will get the bignum that int_ parsed for you.

(In your case, you are getting the warning because you passed in
an int which the word parser takes in as its AA and passes that to
your SA as _1 and you compare to an unsigned)

Now, imagine if we force int_ to always pass _1 with type int.
If you passed a bignum, that will be lossy!

  1) the int_ parser parses a big number, say
     "1234567890123456789012345678901234567"
  2) compiles that into a bignum
  3) converts it to an int (oops)
  4) passes it to your SA

Step no. 3 is problematic. The bignum will be downsized to an int.
Step no. 4 is also problematic because now, there is no way to get
the actual bignum result that was parsed.

(Aside: in spirit-3, BOOST_SPIRIT_ACTIONS_ALLOW_ATTR_COMPAT will
be the default behavior).

Regards,
--
Joel de Guzman
http://www.boostpro.com
http://boost-spirit.com




------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Spirit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Feature request - attribute type should not be altered for terminal rules

Vitaly Budovski-4
On 11 May 2012 11:30, Joel de Guzman <[hidden email]> wrote:

> I probably did not communicate well on IRC. Let me try again.
> So, what is the attribute of the int_ parser? By default, it is
> int. However, if the user passes in his own attribute, the int_
> parser uses its type and it becomes its attribute. Basically, for
> any parser P, we have:
>
>  1) DA: the default attribute type of P (for int_ it is int)
>  2) AA: The actual attribute of P (the one that the user actually provides)
>
> Essentially, P is not tied to its DD (default attribute type). For as long as
> AA (The actual attribute) is 'compatible with' the parser P. It will be
> accepted. For example, your AA can be short for parser int_. That is OK.
> int_ will try to parse as much as it can, but report an error when the
> short overflows. For that matter, it should also be possible to pass in
> user defined types such as bignum for int_. When passed a bignum, the int_
> parser will use it, parse the input, and compute the result (compile the
> bignum).
>
> Semantic actions use the AA attribute when you #define
> BOOST_SPIRIT_ACTIONS_ALLOW_ATTR_COMPAT. That way, if you pass in a
> bignum, your SA will get the bignum that int_ parsed for you.
>
> (In your case, you are getting the warning because you passed in
> an int which the word parser takes in as its AA and passes that to
> your SA as _1 and you compare to an unsigned)
>
> Now, imagine if we force int_ to always pass _1 with type int.
> If you passed a bignum, that will be lossy!
>
>  1) the int_ parser parses a big number, say
>     "1234567890123456789012345678901234567"
>  2) compiles that into a bignum
>  3) converts it to an int (oops)
>  4) passes it to your SA
>
> Step no. 3 is problematic. The bignum will be downsized to an int.
> Step no. 4 is also problematic because now, there is no way to get
> the actual bignum result that was parsed.
>

Perhaps there is a way to introduce a step 2a, which checks
compatibility between the parsed result (bignum) and output result
(int) and issues a warning.
I guess what I'm saying is that Spirit should determine compatibility
between AA and DA.
If the user does the conversion manually to a compatible type e.g.
parse(f, l, _val = bignum_p[if_else_(_1 > 1e200, 5, 6)], int) there
will not be an issue.
Both 5 and 6 are convertible to int without overflow.

> (Aside: in spirit-3, BOOST_SPIRIT_ACTIONS_ALLOW_ATTR_COMPAT will
> be the default behavior).
>
> Regards,
> --
> Joel de Guzman
> http://www.boostpro.com
> http://boost-spirit.com


That is exactly why I have enabled it.
On the subject of spirit-3, perhaps you could write up a brief article
on what you see as the main shortcomings of v2 and what you hope to
achieve in v3.


Cheers,

Vitaly

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Spirit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Feature request - attribute type should not be altered for terminal rules

Joel de Guzman-2
On 5/11/2012 11:10 AM, Vitaly Budovski wrote:

>> Semantic actions use the AA attribute when you #define
>> BOOST_SPIRIT_ACTIONS_ALLOW_ATTR_COMPAT. That way, if you pass in a
>> bignum, your SA will get the bignum that int_ parsed for you.
>>
>> (In your case, you are getting the warning because you passed in
>> an int which the word parser takes in as its AA and passes that to
>> your SA as _1 and you compare to an unsigned)
>>
>> Now, imagine if we force int_ to always pass _1 with type int.
>> If you passed a bignum, that will be lossy!
>>
>>  1) the int_ parser parses a big number, say
>>     "1234567890123456789012345678901234567"
>>  2) compiles that into a bignum
>>  3) converts it to an int (oops)
>>  4) passes it to your SA
>>
>> Step no. 3 is problematic. The bignum will be downsized to an int.
>> Step no. 4 is also problematic because now, there is no way to get
>> the actual bignum result that was parsed.
>>
>
> Perhaps there is a way to introduce a step 2a, which checks
> compatibility between the parsed result (bignum) and output result
> (int) and issues a warning.
> I guess what I'm saying is that Spirit should determine compatibility
> between AA and DA.
> If the user does the conversion manually to a compatible type e.g.
> parse(f, l, _val = bignum_p[if_else_(_1 > 1e200, 5, 6)], int) there
> will not be an issue.
> Both 5 and 6 are convertible to int without overflow.

I see your point.

Perhaps a way to fix this is to introduce the concept of fixed attributes.
I.e. some parsers (e.g. word or even rule) have fixed attributes and
can therefore prevent attribute replacement. If int_ becomes a parser
with a fixed attribute, then it's attribute will always be int. Same for
word; same for rule<I, T()>; or grammar.

Thoughts?

I still have to think this through...

Regards,
--
Joel de Guzman
http://www.boostpro.com
http://boost-spirit.com




------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Spirit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-devel