Ticket #2527 (closed defect: fixed)

Opened 7 months ago

Last modified 7 months ago

Two division signs in an EXPRESSION lead to issues

Reported by: pramsey Assigned to: 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

02/26/08 16:23:12 changed by dmorissette

  • cc set to dmorissette.

02/26/08 17:29:48 changed by sdlime

  • status changed from new to assigned.

02/27/08 23:38:59 changed by sdlime

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

02/28/08 09:47:06 changed by dmorissette

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?

03/01/08 13:11:13 changed by sdlime

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

03/02/08 09:50:44 changed by sdlime

  • status changed from assigned to closed.
  • resolution set to fixed.

Fixed in both the 5.0 branch (r7421) and the dev branch (r7420). Closing...

Steve

03/02/08 12:28:53 changed by pramsey

Thanks Steve!

03/02/08 12:55:54 changed by sdlime

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

03/02/08 19:07:20 changed by tamas

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

03/02/08 20:52:57 changed by sdlime

I plan to, just not from my Mac.

Steve

03/03/08 14:02:31 changed by dmorissette

FYI I have committed new maplexer.c generated with Flex 2.5.31 on Linux in branch 5-0 (r7422) and trunk (r7423).

03/04/08 14:40:52 changed by sdlime

Thanks Dan!