develooper Front page | perl.perl5.porters | Postings from March 2006

Re: how should %^H work with lexical pramas

Thread Previous | Thread Next
Nicholas Clark
March 29, 2006 07:15
Re: how should %^H work with lexical pramas
Message ID:
On Wed, Mar 29, 2006 at 03:15:17PM +0200, Rafael Garcia-Suarez wrote:
> Nicholas Clark wrote:
> > And given that you might want to implement your pragma with more than one
> > level of subroutine, I infer that you might need to get at $^{foo} from
> > somewhere up your caller's scope. This starts to sound like the correct
> > hash should be returned as another value from caller.
> Just like the warnings bitfield, yes.

Logically then if feels like compile time state should be stored in struct

struct cop {
    char *	cop_label;	/* label for this construct */
    char *	cop_stashpv;	/* package line was compiled in */
    char *	cop_file;	/* file name the following line # is from */
    HV *	cop_stash;	/* package line was compiled in */
    GV *	cop_filegv;	/* file the following line # is from */
    U32		cop_seq;	/* parse sequence number */
    I32		cop_arybase;	/* array base this line was compiled with */
    line_t      cop_line;       /* line # of this command */
    SV *	cop_warnings;	/* lexical warnings bitmask */
    SV *	cop_io;		/* lexical IO defaults */

But then that's going to make it tricky to make it read write, as my
understanding was that the optree is shared between threads, so any thread
writing to the field will be scribbling on the state read by all the rest.

> > I was thinking, if at runtime you change the caller's %^H, should that change
> > be reflected in any subsequent string eval they perform? If so, this would
> > mean that eval should be getting its (local compile time) %^H from the
> > current scope's run time %^H-a-like. (The %^H result from caller(-1), not
> > that caller(-1) is legal)
> Yes, currently hints aren't propagated in eval("") (except a few ones,
> ie. some strictures and all warnings).

Where do the other hints bits currently get lost?

I see this in pp_entereval:

    PL_hints = PL_op->op_targ;
    if (saved_hh)
	GvHV(PL_hintgv) = saved_hh;

and as op_targ is at least 32 bits, I was assuming that it had space for all.
So the loss can't be at this point.

Nicholas Clark

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About