Evaluating user-defined conditions

Andrew Beverley andy at andybev.com
Tue Jun 10 11:12:02 BST 2014


On Tue, 2014-06-10 at 11:37 +0200, Abigail wrote:
> On Tue, Jun 10, 2014 at 09:26:17AM +0100, Andrew Beverley wrote:
> > On Tue, 2014-06-10 at 09:20 +0200, Abigail wrote:
> > > >     # Sanitise
> > > >     $_ = $code;
> > > >     return unless /^[ \S]+$/;               # Only allow normal spaces
> > > >     return if /[\[\]]+/;                    # No brackets should remain
> > > >     return if /\\/;                         # No escapes please
> > > >     s/"[^"]+"//g;                           # Remove quoted strings
> > > >     m!^([-()*+/0-9<> ]|&&|eq)+$! or return; # Allowed expression chars
> > > 
> > > 
> > > So, you excluding having any alpha char (except 'eq') in the resulting
> > > expression? Because that's what the last line does. Perhaps that's your
> > > intention, because I've no idea what $value is going to be, other than
> > > "it could be a string in quotes".
> > 
> > Yes, $value is either an integer or a string in quotes. The 2 lines
> > previous to the last line should remove any string in quotes, therefore
> > just leaving operators and integers?
> 
> 
> So, your loop replaces [$var] with a string in quotes, only for s/"[^"]+"//g;
> to remove it? I'm a bit confused what purpose that serves.

The code that's run is what is in-between those 2 statements. The latter
is a sanity check. I didn't explain that properly.

> Considering that you want to be really restrictive, a parser is going to
> be quite simple. Why not just write a parser instead of hoping you've
> catched anything potentially bad? 

Because it was 2am and I needed something for a demo today ;-)
But yes, I agree that's the best way.

Thanks,

Andy




More information about the london.pm mailing list