develooper Front page | perl.perl5.porters | Postings from September 2013

[perl #119823] LABEL<newline>: only works in string eval

Thread Previous
From:
Father Chrysostomos via RT
Date:
September 15, 2013 22:32
Subject:
[perl #119823] LABEL<newline>: only works in string eval
Message ID:
rt-3.6.HEAD-1873-1379284315-902.119823-14-0@perl.org
On Sun Sep 15 14:32:09 2013, Hugmeir wrote:
> On Sun, Sep 15, 2013 at 5:45 PM, Father Chrysostomos <
> perlbug-followup@perl.org> wrote:
> 
> > # New Ticket Created by  Father Chrysostomos
> > # Please include the string:  [perl #119823]
> > # in the subject line of all future correspondence about this issue.
> > # <URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=119823 >
> >
> >
> > $ ./perl -Ilib -MO=Deparse -e 'foo:bar'
> > foo: '???';
> > -e syntax OK
> > $ ./perl -Ilib -MO=Deparse -e 'foo' -e ':bar'
> > syntax error at -e line 2, near "foo
> > :"
> > -e had compilation errors.
> > $ ./perl -Ilib -e 'warn eval "foo\n:bar";'
> > bar at -e line 1.
> >
> >
> > The colon search does not like newlines, except in string eval, where it
> > is fine.
> >
> 
> This probably happens because the code that skips whitespace preceding the
> colon search is 'while (d < PL_bufend && isSPACE(*d)) d++;', which is
wrong
> if there can be a newline between the end of the current token and the
> start of the next, since for the non-eval case we're reading from a file
> and PL_bufend will point to the next \n.

Yes, that is the cause.


> Ideally we should be using PEEKSPACE() there, but that calls
> lex_read_space, which swallows up # and anything following it, and that
> would break s#foo#bar#.
> So the groundwork to get this and similar bugs fixed would be, I think,
> adding a LEX_NO_SWALLOW_COMMENTS-style flag for
> lex_read_space/skipspace_flags.

I think that would work.

-- 

Father Chrysostomos


Thread Previous


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About