bugBRILLANT - Bugs: bug #17657, == - 1 .. 9999

Show feedback again

You are not allowed to post comments on this tracker with your current authentification level.

bug #17657: == - 1 .. 9999

Submitted by:  Georges Mariano <gmariano>
Submitted on:  Sun Feb 6 10:11:50 2011  
Category: DevelopmentModule: BCaml/Bparser
Priority: 5 - NormalSeverity: 4 - Important
Status: In ProgressPrivacy: Public
Assigned to: Samuel Colin <scolin>Open/Closed: Open

Tue Apr 26 22:24:40 2011, comment #3:

Small update, I think I found the cause of the bug. This is most likely due to a shift/reduce conflict we have not resolved.

As the default behaviour in that case is to shift, the whole "-1..99" expression is put on the stack, where (1..99) is reduced (to an interval) and then (- expr) is reduced, leading to the observed inconsistency.

The interpretation is that the current grammar is, oddly enough, still too liberal in certain places. As my current focus on the grammar involves solving also shift/reduce conflicts, this bug shall be solved with a better version of the grammar.

I shall add a unit test for ensuring this bug is solved as well.

Samuel Colin <scolin>
Project AdministratorIn charge of this item.
Mon Feb 7 21:51:21 2011, comment #2:

Bug confirmed, but it has nothing to do with definitions, it is indeed a bparser bug.

The bug is still present in my local changes to the grammar, despite the fact that the priorities are all well described. Normally, wrt priorities, -1 .. 99 (no matter if there is a space or not) should be parsed as (-1) .. 99 because the unary minus has a bigger priority than the range operator.

I shall try to see where exactly in the grammar this problem arises.

Samuel Colin <scolin>
Project AdministratorIn charge of this item.
Sun Feb 6 10:51:43 2011, comment #1:

Seems that there is a real bug in blexer/bparser

Dirty patch of bparser is under (regression) test ;)

'dirty' means that, for now, the number of shift/reduce conflicts is increased.

Georges Mariano <gmariano>
Project Administrator
Sun Feb 6 10:11:50 2011, original submission:

A definition like the following one :

X == - 1 .. 9999 (note there is a space between - en 1)

leads to (syntactically) incorrect POs.

don't know exactly if it is a bug in the bparser (new definitions "machinery" contributed by Samuel) but two comments are induced :

  • intervall specification shoud always be enclosed in ( )

/this a B'[*] suggestion, mainly to protect the intervall syntax from the context of expansion/

  • may be, we should require that negative numbers should always be written without space...

quickly grep'ing in bparser/lib seems to show that we only deal with "positive numbers"

[*] This is "soft" B' because '('intervall')' are already accepted by the B language, we just say that ( ) are mandatory.

Georges Mariano <gmariano>
Project Administrator


No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by scolin (Posted a comment)
  • -unavailable- added by gmariano (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Error: not logged in



    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue Apr 26 22:24:40 2011scolinAssigned togmariano=>scolin
    Sun Feb 6 10:51:43 2011gmarianoSeverity3 - Normal=>4 - Important
      StatusNeed Info=>In Progress
      Assigned toNone=>gmariano
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup