demerphq at gmail
Nov 6, 2009, 1:56 AM
Post #4 of 4
(43 views)
Permalink
|
|
Re: [perl #70151] eval localises %^H at runtime, maybe relates to [perl #62056] [perl #56444]
[In reply to]
|
|
2009/11/5 karl williamson <public[at]khwilliamson.com>:
> demerphq wrote:
>>
>> 2009/11/4 karl williamson <public[at]khwilliamson.com>:
>>>
>>> Zefram (via RT) wrote:
>>>>
>>>> # New Ticket Created by Zefram # Please include the string: [perl
>>>> #70151]
>>>> # in the subject line of all future correspondence about this issue. #
>>>> <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=70151 >
>>>>
>>>>
>>>>
>>>> This is a bug report for perl from zefram[at]fysh.org,
>>>> generated with the help of perlbug 1.36 running under perl 5.10.0.
>>>>
>>>>
>>>> -----------------------------------------------------------------
>>>> [Please enter your report here]
>>>>
>>>> $ perl -lwe 'BEGIN { $^H{foo}=1; } BEGIN { eval q{ $^H{bar} = 1; }; }
>>>> BEGIN { print "foo=$^H{foo}, bar=$^H{bar}"; }'
>>>> Use of uninitialized value in concatenation (.) or string at -e line 1.
>>>> foo=1, bar=
>>>>
>>>> The execution of the string-evaled code takes place with %^H, and a
>>>> bunch
>>>> of other things, localised in a block that was set up to localise them
>>>> for *compilation* of the string-evaled code.
>>>>
>>>> I described this on p5p last week, mainly concerned with PL_compcv
>>>> which is one of the other things that gets localised. I'd found a
>>>> handful of situations with this behaviour: do "FILE", require, and
>>>> string eval. I asked whether the behaviour was intentional, but got
>>>> no reply. On further investigation and pondering, I've found that all
>>>> the situations doing this are based on doeval() in pp_ctl.c, and I've
>>>> decided that it's a bug.
>>>>
>>>> I had a go at modifying doeval() and its callers to avoid the problem,
>>>> but I've so far failed to produce a fix. The current block arrangement
>>>> is
>>>> deeply embedded in the structure of the code, such that it is not
>>>> amenable
>>>> to making the compiled op tree survive outside the compilation scope.
>>>> Fixing it will be a bigger job than I initially anticipated.
>>>>
>>>> Marginally relevant: my Parse::Perl module, if used as a direct
>>>> replacement for string eval, does not exhibit this problem. It fully
>>>> separates the parsing and execution stages, using code that is derived
>>>> from pp_entereval() and doeval() but handles the resulting op tree in
>>>> a completely different way.
>>>>
>>> I wonder if this is has any bearing on [perl #56444] and [perl #62056]
>>> in which the hint is 0 for charnames when it shouldn't be for regcomp.c
>>
>> Im pretty sure not, im pretty sure that charnames problem is just a
>> fundamental probelm of doing late resolution of the charnames.
>>
>> I think i explained this before somewhere....
...
> What I know is that looking at this with gdb, the bit was 0 when I, perhaps
> in my ignorance, thought it should be 1.
The hints problem probably does lead to problems with charnames in
some situations.
But even if it didn't we would still have problems with charnames due
the late resolution of the escape.
If we fix the escape problem the hints problem will be irrelevant to
the regex engine.
In other words the hints problem exposes an aspect of the underlying
bug in the regex engine* but is not its cause.
Cheers,
Yves
* although im a tiny bit reluctant to call it a bug, it is a feature
conflict at a conceptual level
--
perl -Mre=debug -e "/just|another|perl|hacker/"
|
