[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#23635: closed (possible bug in \c escape handling)

From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#23635: closed (possible bug in \c escape handling)
Date: Mon, 30 May 2016 02:01:02 +0000

Your message dated Sun, 29 May 2016 19:00:25 -0700
with message-id <address@hidden>
and subject line Re: bug#23635: possible bug in \c escape handling
has caused the debbugs.gnu.org bug report #23635,
regarding possible bug in \c escape handling
to be marked as done.

(If you believe you have received this mail in error, please contact

23635: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=23635
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: possible bug in \c escape handling Date: Fri, 27 May 2016 21:08:21 -0400 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0

There might be a small bug in processing of GNU extension escape sequence "\c".

When the character following "\c" is a backslash, the code consumes only one 
character, leading to inconsistent and incorrect output.

  $ echo a | sed 's/./\c\\/' | od -c
  0000000 034 \ \n
  $ echo a | sed 's/./\c\d/' | od -c
  0000000 034 d \n


  $ echo a | sed 's/./\c\/' | od -c
  sed: -e expression #1, char 8: unterminated `s' command

Meaning there is no way to generate the character '\x034' alone with "\c".

This is also somewhat inconsistent because it consumes a single backslash 
(whereas everywhere else a single backslash is the escape character itself).

For comparison, other characters behave as expected:

  $ sed 's/./\cA/' in | od -c
  0000000 001 \n
  $ sed 's/./\c[/' in | od -c
  0000000 033 \n
  $ sed 's/./\c]/' in | od -c
  0000000 035 \n

As a side effect, it could also be confusing if the syntax allows 'recursive' 
such as "\c\x41", which might be argued to be '\c' of the following character,
which should be first evaluated as \x61, resulting in "\cA".

The attached patch fixes the problem with the following rules:
1. '\c\\' = Control-Backslash = ASCII 0x34.
2. Any other backslash combinations after "\c" are rejected, and sed aborts.

Tests included. comments are welcomed.

- assaf

Attachment: 0001-sed-reject-recursive-escaping-after-c.patch
Description: Text Data

--- End Message ---
--- Begin Message --- Subject: Re: bug#23635: possible bug in \c escape handling Date: Sun, 29 May 2016 19:00:25 -0700
On Sat, May 28, 2016 at 8:40 PM, Jim Meyering <address@hidden> wrote:
> On Sat, May 28, 2016 at 7:31 PM, Assaf Gordon <address@hidden> wrote:
>> Hello,
>> Thank you for the review.
>> Attached an improved version.
>> Regarding when the bug was introduced (in the 'NEWS'), version 3.02 did not 
>> support \c escapes, and version 4.0.6 had this bug (as does the first git 
>> commit). I wrote:
>>     [bug introduced in the sed-4.0.* releases]
> Thanks for the quick update!
> One more thing I noticed is that you use here docs
> that interpolate. Just as I prefer to use single-quoted strings
> most of the time, e.g., to avoid having to backslash-escape
> every backslash, I prefer to use quoted here docs as in the
> attached. Also, I prefer to space-delimit operators like '<', '<<', and '>'.
> At least on one side.
> Also, I removed a stray "EOF" after the final "Exit..." line.
> Here's the proposed delta, on top of your patch:

I've pushed your patch amended with that change, and tweaked the log
message to have these lines: capitalized first word of each sentence
and added the (T) and (Bug fixes) qualifiers:

    * sed/compile.c: (RECURSIVE_ESCAPE_C): New error message.
    (normalize_text): Check for \c-backslash, reject recursive escaping.
    * testsuite/recursive-escape-c.sh: New file. Test new behaviour.
    * testsuite/Makefile.am (T): Add new test.
    * NEWS (Bug fixes): Mention it.

Thanks again.
As I write this, I realized that I should have referenced the bug
report URL in the commit log.  Oh well.

--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]