Note that it isn't just empty alternations such as "x||y". This affects any alternation where the length of the alternatives is not equal to one. So it also affects "a|xy|b" and "a|b*|c" but not "a|b|c". For any regex written by a human, where the number of alternate expressions is small, the cost to compile this pattern isn't a problem. But, as the O.P. points out, it could be used as a DOS vector by stringing together a huge number of alternatives using the "|" operator.

P.S., I haven't looked at the source code but it appears that "a|b" is treated as "[ab]" based on the runtime cost of compiling such a regex when that pattern is extremely long. However, "aa|bb" does not receive that special treatment as it is also quite costly to compile when that pattern is repeated thousands of times.

CC @rsc in case this has already been addressed in RE2.

@krader1961 If it happens with longer alternations too, though we don't need to worry about it for regexes written by humans, it could be an issue with regexes written by computers. If I remember right, I've seen JS profanity filters that had their banned word list as a regex, all joined by pipe characters. That style of regex could be a problem if it has thousands of words.

Unsurprisingly, "append" is essentially identical in RE2.

Fixed in RE2 as per google/re2@e9d5179. Who wants to make the corresponding change for Go?

@junyer I'll give it a try.

Change https://golang.org/cl/238079 mentions this issue: regexp/syntax: append patchLists in constant time