During identifier parsing, handle undefined escape sequences

in the same way as groff:
* \\ is always reduced to \
* \. is always reduced to .
* other undefined escape sequences are usually reduced to the escape name,
for example \G to G, except during the expansion of expanding escape
sequences having the standard argument form (in particular \* and \n),
in which case the backslash is preserved literally.

Yes, this is confusing indeed.
For example, the following have the same meaning:
* .ds \.   and   .ds .     which is not the same as   .ds \\.
* \*[\.]   and   \*[.]     which is not the same as   \*[\\.]
* .ds \G   and   .ds G     which is not the same as   .ds \\G
* \*[\G]   and   \*[\\G]   which is not the same as   \*[G]   <- sic!

To feel less dirty, have a leaning toothpick, if you are so inclined.

This patch also slightly improves the string shown by the "escaped
character not allowed in a name" error message.

1 files changed, 27 insertions, 2 deletions

diff --git a/regress/roff/cond/string.in b/regress/roff/cond/string.in
index 273984be..fedb4d81 100644
--- a/regress/roff/cond/string.in
+++ b/regress/roff/cond/string.in
@@ -1,5 +1,5 @@
-.\" $OpenBSD: string.in,v 1.4 2019/02/06 20:54:28 schwarze Exp $
-.TH STRING 1 "February 6, 2019"
+.\" $OpenBSD: string.in,v 1.5 2022/06/03 11:50:25 schwarze Exp $
+.TH STRING 1 "June 3, 2022"
 .SH NAME
 string \- conditional testing whether a string is defined
 .SH DESCRIPTION
@@ -40,3 +40,28 @@ identifier and tab:
 escape sequence after identifier:
 .ie d mystr\(enmystr is defined
 .el OOPS
+.PP
+backslash in name:
+.ds \\ value
+.ie d \\ \e is defined
+.el OOPS
+.rm \\
+.if d \\ still defined!?
+.PP
+dot in name:
+.ds . value
+.ie d . \&. is defined
+.el OOPS
+.ie d \. \e. is defined
+.el OOPS
+.rm .
+.if d . still defined!?
+.PP
+invalid escape in name:
+.ds G value
+.ie d G G is defined
+.el OOPS
+.ie d \G \eG is defined
+.el OOPS
+.rm \G
+.if d G still defined!?