[v3,2/9] gas: respect CR_EOL also for scrubbing

Message ID e9911121-3d68-48ec-99a1-4394f749696e@suse.com
State New
Headers
Series gas: scrubber adjustments |

Commit Message

Jan Beulich July 31, 2024, 11:55 a.m. UTC
  While apparently intended to be only externally controlled (e.g. via
specifying CFLAGS at make invocation), we should still keep scrubber and
lexer in sync in this regard. There's one place which imo was previously
wrong already, but would go further wrong and hence is being adjusted
right here: An .mri directive can be terminated by any kind of "line"
(really: statement) separators.
---
Btw, is it actually correct to honor line_comment_chars[] after other
than a physical line break (LEX_IS_NEWLINE), possibly followed by
whitespace? Aren't these forms of comments meant to remove entire
physical lines only, but not tails thereof? After all the processing of
such a comment looks for a newline, not just a line separator.
---
v3: New.
  

Patch

--- a/gas/app.c
+++ b/gas/app.c
@@ -93,7 +93,11 @@  static char last_char;
 static char lex[256] = {
   [' ']  = LEX_IS_WHITESPACE,
   ['\t'] = LEX_IS_WHITESPACE,
+#ifdef CR_EOL
+  ['\r'] = LEX_IS_LINE_SEPARATOR,
+#else
   ['\r'] = LEX_IS_WHITESPACE,
+#endif
   ['\n'] = LEX_IS_NEWLINE,
   [':'] = LEX_IS_COLON,
   ['$'] = LEX_IS_SYMBOL_COMPONENT,
@@ -862,7 +866,9 @@  do_scrub_chars (size_t (*get) (char *, s
 	      ++mri_state;
 	    }
 	  else if (*mri_state != '\0'
-		   || (!IS_WHITESPACE (ch) && !IS_NEWLINE (ch)))
+		   || (!IS_WHITESPACE (ch)
+		       && !IS_LINE_SEPARATOR (ch)
+		       && !IS_NEWLINE (ch)))
 	    {
 	      /* We did not get the expected character, or we didn't
 		 get a valid terminating character after seeing the