Ambiguous regex escape \num

According to this reference, there are two escape sequences \n and \num where n is an octal number, and num is a positive integer. The former is an escape value that gets converted to a character, and the latter is a back-reference.

Isn't that ambiguous? How can the regex tell them apart? When does it decide to use one over th开发者_JS百科e other?

---

The rules of disambiguation are described in http://msdn.microsoft.com/en-us/library/thwdfzxy.aspx:

---

Note the ambiguity between octal escape codes (such as \16) and \number backreferences that use the same notation. This ambiguity is resolved as follows:

• The expressions \1 through \9 are always interpreted as backreferences, and not as octal codes.

• If the first digit of a multidigit expression is 8 or 9 (such as \80 or \91), the expression as interpreted as a literal.

• Expressions from \10 and greater are considered backreferences if there is a backreference corresponding to that number; otherwise, they are interpreted as octal codes.

• If a regular expression contains a backreference to an undefined group number, a parsing error occurs, and the regular expression engine throws an ArgumentException.

---

Yes, it's ambiguous.. but if you look through MSDN documentation here it's explained how it is solved:

Note the ambiguity between octal escape codes (such as \16) and \number backreferences that use the same notation. This ambiguity is resolved as follows:

The expressions \1 through \9 are always interpreted as backreferences, and not as octal codes.

If the first digit of a multidigit expression is 8 or 9 (such as \80 or \91), the expression as interpreted as a literal.

Expressions from \10 and greater are considered backreferences if there is a backreference corresponding to that number; otherwise, they are interpreted as octal codes.

If a regular expression contains a backreference to an undefined group number, a parsing error occurs, and the regular expression engine throws an ArgumentException.

Really a silly choice to have the same syntax for both elements, since you can generate weird bugs if you don't follow this precise reference to how the ambiguity is solved.

---

Yes it is ambiguous. I will venture that the ambiguity is resolved in favour of interpreting it as backreferences. If an octal number is truly desired, it can always be prefixed with 0.

---

I think it tries to match a backreference and if it fails, it attempts a octal number match.

http://msdn.microsoft.com/en-us/library/1400241x%28VS.85%29.aspx