Here's a second patch that makes the surrounding comments more in line with the code, in my opinion.
On Wed, 25 Oct 2017 at 09:38 Pieter Kockx <[email protected]> wrote: > Hello everyone > > sed 's/[[x=]//' > > 's/[[x=]//' was parsed as 's/[[=x]//' which (correctly) > raises an error because the "second delimiter is missing", here =]. > > The two got mixed up because the parser didn't return to > the "inside bracket"-state after encountering an opening bracket > while inside the bracket expression. > > -- Pieter >
From 6f751f4f7d291152e335a06900d33f4f0ec0dbdb Mon Sep 17 00:00:00 2001 From: Pieter Kockx <[email protected]> Date: Wed, 25 Oct 2017 09:42:49 +0200 Subject: [PATCH 2/2] sed: Clarify comments in find_delim --- sed.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/sed.c b/sed.c index 4585f17..0301fbc 100644 --- a/sed.c +++ b/sed.c @@ -522,12 +522,12 @@ static char * find_delim(char *s, Rune delim, int do_brackets) { enum { - OUTSIDE , /* not in brackets */ - BRACKETS_OPENING, /* last char was first [ or last two were first [^ */ + OUTSIDE , /* not inside [] */ + BRACKETS_OPENING, /* almost inside [], last Runes were [ or [^ */ BRACKETS_INSIDE , /* inside [] */ - INSIDE_OPENING , /* inside [] and last char was [ */ - CLASS_INSIDE , /* inside class [::], or colating element [..] or [==], inside [] */ - CLASS_CLOSING , /* inside class [::], or colating element [..] or [==], and last character was the respective : . or = */ + INSIDE_OPENING , /* inside [] and maybe inside 'class', last Rune was [ */ + CLASS_INSIDE , /* inside [] and inside 'class' i.e. [::], [..], or [==] */ + CLASS_CLOSING , /* inside [] and inside 'class', last Rune was the respective c */ } state = OUTSIDE; Rune r, c = 0; /* no c won't be used uninitialized, shutup -Wall */ -- 2.13.5
