GNU bug report logs - #23635
possible bug in \c escape handling

Previous Next

Full log

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Assaf Gordon <assafgordon <at> gmail.com>
To: bug-sed <at> gnu.org
Subject: possible bug in \c escape handling
Date: Fri, 27 May 2016 21:08:21 -0400

[Message part 1 (text/plain, inline)]

Hello,

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.
Example:

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

but:

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

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

This is also somewhat inconsistent because it consumes a single backslash character
(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
  0000002
  $ sed 's/./\c[/' in | od -c
  0000000 033 \n
  0000002
  $ sed 's/./\c]/' in | od -c
  0000000 035 \n
  0000002

As a side effect, it could also be confusing if the syntax allows 'recursive' escapes,
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

[0001-sed-reject-recursive-escaping-after-c.patch (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.