Broken error message when terminating input of triple quoted string

[markuspf]

On current master the following happens (I hit Ctrl-D on the second continuation line).

gap> obj := """
> 
> 
Syntax error: String must end with " before end of file
�^

[ChrisJefferson]

Just checking is the problem you are refering to one in particular, or all 3 of:

1. The reference to " instead of """

2. The reference to end of file

3. The weird question mark character on the next line.

[markuspf]

All three of them, I'd say.

[ChrisJefferson]

I can't reproduce the "weird ? inside square" problem. Can you tell me where/how you can produce it?

[fingolfin]

@ChrisJefferson I can reproduce it just fine, on Mac OS X. Just pasted gap> obj := """, pressed return twice, then ctrl-D. Happens when I start gap with -A and also without.

[fingolfin]

BTW, the message "end of file" does make some sense given that ctrl-D normally marks the EOF. But we could perhaps change this to "end of input" to make it less confusing?

[fingolfin]

The weird output is printed by function SyntaxErrorOrWarning, this part of it:

        // print the current line
        const char * line = GetInputLineBuffer();
        Pr("%s", (Int)line, 0);

The line buffer contains the bytes 0xff 0x00 (i.e. EOF followed by NUL), which gives the � diamond with question mark. Then, it next prints ^ to mark the place in which the syntax error occurred, which gives the rest of the "weird" message.

[fingolfin]

Some further notes: some time ago the first issue was fixed, i.e. the error message now references """ for triple strings, not ".

What happens here is that all data on an input line is exhausted, so GAP asks for more via GetLine, but that encounters an EOF == -1. This overwrites the previous line data, and finally SyntaxError prints it.

Variants of this issue can actually also be triggered in older GAP versions, e.g. using EvalString. This is in GAP 4.6.5:

gap> EvalString("Length(\"x");
Syntax error: string must end with " before end of file in stream line 1
�^
Error, Could not evaluate string.
 called from
<function "EvalString">( <arguments> )
 called from read-eval loop at line 1 of *stdin*
you can 'quit;' to quit to outer loop, or
you can 'return;' to continue
brk>

One possible fix is to modify SyntaxError to not show the "previous" line if it starts with an EOF.

Nicer would be if GetLine did not indicate EOF by overwriting the line buffer with it, but rather by some other means; e.g. it could set some kind of eof flag in IO()->Input. Then change GET_CHAR to detect that flag, and just return the EOF byte (or even better: changing it to return Int not Char, matching what POSIX getc and getchar do; only allow -1 (for error), and values which can be safely (without overflow) cast to an (unsigned) char.

Then we could also get rid of this hack in NextSymbol in scanner.c, which replaces the EOF char in STATE(In) by a null byte.

  case '\377':      STATE(Symbol) = S_EOF;           *STATE(In) = '\0'; break;