#2527 closed defect (fixed)
Two division signs in an EXPRESSION lead to issues
Reported by: | pramsey | Owned by: | sdlime |
---|---|---|---|
Priority: | normal | Milestone: | 5.0.3 release |
Component: | MapServer C Library | Version: | 5.0 |
Severity: | normal | Keywords: | |
Cc: | dmorissette |
Description
This fails (returns no features, even though it's true)
EXPRESSION (3>2/1 and 2/2<6)
This succeeds (catches all features)
EXPRESSION (3>2*1 and 2*2<6)
damno "wonders if the / ... / may be seen as a regex?"
Change History (12)
comment:1 by , 16 years ago
Cc: | added |
---|
comment:2 by , 16 years ago
Status: | new → assigned |
---|
comment:3 by , 16 years ago
comment:4 by , 16 years ago
I'd have a preference for keeping the syntax if we can, not only for backwards compatibility, but also for expression readability.
i.e. this
EXPRESSION ([name] =~ /regex_here/)
is much more intuitive than this
EXPRESSION ([name] =~ 'regex_here')
Is the parser sequential or does it have the concept of priority of tokens? Could we make it so that if the division are enclosed inside brackets like this
EXPRESSION (3>(2/1) and (2/2)<6)
then the divisions are parsed as single entities before the are processed as a regex?
comment:5 by , 16 years ago
Actually I think I can set a lexer state so that means regex only after first seeing =~. Otherwise /'s would be seeing as division operators. Trying that now...
Steve
comment:6 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:8 by , 16 years ago
I should note that I tested Paul's test expressions and a bunch of others using the "testexpr" program. I didn't actually try it in a drawing context. Paul, might be nice to quick run your test case and confirm the fix.
Steve
comment:9 by , 16 years ago
Steve,
You should also update the lexer output in the trunk and the stable branch to avoid the current build issues. See the buildbot for more details.
Tamas
Danmo is correct. Argh...
Without reading the flex documentation there are a couple of possible solutions although none are particularly appealing. One would be to lose the delimiter for regex in the expression context. We already have the =~ operator so we could simply use that to know when to interpret a string as an expression. The other idea would be to track the most recent operator so that mean regex only if proceeded by a =~. That adds complexity to the tokenizing. You'd have to make sure to initialize the last operator variable correctly etc... which could get messy. The problem with the first idea is that it would break backwards compatability but would simplify the code.
Thoughts?
Steve