Re^4: The safety of string eval and block eval.

[afoken]

As a very generic rule of thumb: If you think that you need a string eval, you are doing it wrong.

There are very few good reasons for using a string eval, and even fewer if the string eval has to work on input controlled by the user. use, require, and the rare do FILENAME, are of course string evals behind the scenes, and they are useful and the proper way to load perl code from files.

In very rare cases, perl functions have to be generated from data at run time, and at that point, a string eval is actually the best way to solve the problem. But for tasks like parsing configuration files, "variable variable names", constructing variables at run-time, reading data back from stored files (e.g. from Data::Dumper), string eval is the wrong way. Configuration files are better stored as INI files, JSON or XML (all readable and all without executable code). "Variable variable names" and variables constructed at runtime are better implemented via arrays, hashes, or (worst case) symbol table manipulation. And data is better stored using JSON, XML, one of the various "universal" binary storage formats (see Re^4: Storing state of execution -- Sereal?), or the problematic (see Re: Perl Storable problem (i Think) but fast Storable.

See also: Re^2: Storing state of execution, Re^4: Storing state of execution

And of course, for a quick hack that runs on known data, string eval is ok if it does the job AND the quick hack does not leave your environment. Don't let users use any tool that uses string eval just because it needs less code than a proper solution.

Alexander

[haukex]

Hi afoken,

But for tasks like parsing configuration files ...

Shameless plug of my own module ;-) Undumping Perl

Regards,
-- Hauke D