Front page | perl.perl5.porters |
Postings from August 2013
Re: [perl #119191] "\c\" is a syntax error
Thread Previous
From:
Brian Fraser
Date:
August 7, 2013 16:44
Subject:
Re: [perl #119191] "\c\" is a syntax error
Message ID:
CA+nL+naeWrodyeD=9AwOyXyJ69h5t004r_w63kUc1-nCaF3-tg@mail.gmail.com
On Wed, Aug 7, 2013 at 11:52 AM, Karl Williamson <public@khwilliamson.com>wrote:
> On 08/07/2013 08:14 AM, l.mai@web.de (via RT) wrote:
>
>> # New Ticket Created by l.mai@web.de
>> # Please include the string: [perl #119191]
>> # in the subject line of all future correspondence about this issue.
>> # <URL: https://rt.perl.org:443/rt3/**Ticket/Display.html?id=119191<https://rt.perl.org:443/rt3/Ticket/Display.html?id=119191>>
>>
>>
>>
>> This is a bug report for perl from l.mai@web.de,
>> generated with the help of perlbug 1.39 running under perl 5.18.0.
>>
>>
>> ------------------------------**------------------------------**-----
>> [Please describe your issue here]
>>
>> % perl -we 'printf "%vd\n", "\c\"'
>> Can't find string terminator '"' anywhere before EOF at -e line 1.
>> % perl -we 'printf "%vd\n", "\c\\"'
>> 28.92
>> % perl -we 'printf "%vd\n", "\x1c\\"'
>> 28.92
>>
>> There's no way to get a CTRL-\ (0x1C) with perl's \c notation.
>>
>> The obvious syntax "\c\" is a syntax error.
>>
>> The next try "\c\\" parses but ends up being a 2-character string
>> consisting of
>> CTRL-\ and \ (backslash).
>>
>> I think the latter case is definitely a bug because the middle backslash
>> ends
>> up doing double duty: it is used by \c to form \c\ (0x1C), but then also
>> escapes the third backslash to form \\ (0x5C). This half-reparsing
>> shouldn't
>> happen.
>>
>> And for consistency with other control characters it would be nice if you
>> could
>> get a ^\ by writing "\c\".
>>
>> (This bug may be a duplicate but when I search RT for "\c\" I get 693
>> pages of
>> no results.)
>>
>>
> From perlop:
>
> "Also, "\c\X" yields " chr(28) . "X"" for any X, but cannot come at the
> end of a string, because the backslash would be parsed as escaping the end
> quote.
>
> ...
>
> "Also no attention is paid to "\c\" (multichar control char syntax) during
> this search. Thus the second "\" in "qq/\c\/" is interpreted as a part of
> "\/", and the following "/" is not recognized as a delimiter. Instead, use
> "\034" or "\x1c" at the end of quoted constructs."
>
> The latter quote from the section about the "Gory details of parsing"
>
>
>
Hm. That really sounds more like it's documenting a bug. That being said,
without looking at the code, I imagine that fixing it would make the
parsing of all strings ever so slightly slower to get around one edge case,
so perhaps it's better this way.
Thread Previous