From 798dc914c398c7c040331cbc085457859797cc6f Mon Sep 17 00:00:00 2001 From: Karl Williamson Date: Tue, 18 Jun 2013 14:23:57 -0600 Subject: [PATCH] perlfunc: Add caveat about string eval containing NV scalar --- pod/perlfunc.pod | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/pod/perlfunc.pod b/pod/perlfunc.pod index 2e603ca..4562b2c 100644 --- a/pod/perlfunc.pod +++ b/pod/perlfunc.pod @@ -1777,7 +1777,8 @@ X X =for Pod::Functions catch exceptions or compile and run code -In the first form, the return value of EXPR is parsed and executed as if it +In the first form, often referred to as a "string eval", the return +value of EXPR is parsed and executed as if it were a little Perl program. The value of the expression (which is itself determined within scalar context) is first parsed, and if there were no errors, executed as a block within the lexical context of the current Perl @@ -1800,6 +1801,12 @@ scope that is still compiling. See also the L keyword, which always treats its input as a byte stream and works properly with source filters, and the L pragma. +Problems can arise if the string expands a scalar containing a floating +point number. That scalar can expand to letters, such as C<"NaN"> or +C<"Infinity">; or, within the scope of a C, the decimal +point character may be something other than a dot (such as a comma). +None of these are likely to parse as you are likely expecting. + In the second form, the code within the BLOCK is parsed only once--at the same time the code surrounding the C itself was parsed--and executed within the context of the current Perl program. This form is typically -- 1.8.3.1