Re: [PATCH] [Outreachy] git/userdiff.c fix regex pattern error

[Junio C Hamano <gitster@pobox.com>]

Ananya Krishna Maram <ananyakittu1997@gmail.com> writes:

>> But it does not need to be escaped, when you specify the regular
>> expression the way we do. And the way we specified it is really the
>> standard when specifying regular expressions in C code, i.e. *without* the
>> suggested backslash.
>
> Aha!. this makes total sense. I was thinking from a general regular expression
> point of view. But I should be thinking from C point of view and how C
> might interpret this newly submitted string.

If you were thinking from a general regex point of view, you would
never have treated '/' as anything special, though.

Historically, some languages (like sed and perl) had an regexp match
operator, which is denoted by enclosing a regexp inside a pair of
slashes.  In these languages, if you use /<regexp>/ operator, and if
you want to match slash with the pattern, you somehow need a way to
write an regexp that has slash in it.  E.g. if you want a pattern
that would match 'a' followed by '/' followed by 'b', your regexp
would look like "a/b", but the regexp match operation you would
write in these languages would be like /a\/b/, so that '/<regexp>/'
parser can tell that the second slash is not a slash that signals
the end of the match operator.

And then there is an unnamed misdesigned language that has a
regmatch() function, which takes a string that contains a regular
expression, but somehow requires that string to begin and end with a
slash for no justifiable reason ;-).  If you were thinking about
regexp from that brain-dead languages' point of view, yes, you
should unlearn it and what Dscho gave you would make sense.

C's regexp(3) library does not share such a misdesign and just takes
a regular expression as a string.  You would still need to follow
the quoting rules of C string literals (e.g. write a literal
double-quote or backslash after an escaping backslash), but of
course slash is not special there.