in reply to Re^3: Storing state of execution
in thread Storing state of execution

I prefer to have a storage format that by definition can not contain executable code instead of relying on a filter that tries to prevent malicious code execution inside a string eval. One bug in Safe and the "SafestUndumper" is no longer save, but instead happily executes malicious code.

Also, the "non-executable" formats force the programmer to use a parser. There is no way to accidentally or intentionally use a string eval on those formats.

So, who would intentionally use a string eval on untrusted code?

A little bit of bean counting:

Actually, every storage format that can contain strings can - in theory - also contain executable Perl code. But when reading back formats like XML or JSON, an explicit string eval on an extracted string is required, and that string eval is not present in the library reading the file format (or, at least, it should not be present).

Oh, and string eval means more than just eval $string:

And finally: Any Javascript compiler/interpreter must be able to read and execute JSON, as it is a very restricted subset of Javascript/ECMAScript. That also means that using Javascripts eval (always a string eval) to read JSON is a tempting, but stupid idea, on the same level as using Perl's string eval to read Data::Dumper output. Since ECMAScript Fifth Edition (2009), there is a special JSON parser embedded in the Javascript environment (see


Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)