Fix printing of GAP strings containing null characters (skip them instead of truncating the string)

[nskeip]

Fixes #4120.

Print function used to have a problem: if a GAP string contained a null character, then the string was printed only up to the null character (which is an expected behavior for traditional C strings). Now a GAP string conaining a null character would be printed from start to end and the null character would be skipped.

Text for release notes

See title.

[ChrisJefferson]

This definately improves things. I notice there are other cases in that function which have the same issue (stopping parsing strings at null), but I'm not sure if those are easy for users to call.

[james-d-mitchell]

I think I'd prefer this if the printed output included the \0 character, I.e. so that the output was the same as that of ViewObj but without the ". This'd be less astonishing in my opinion.

[nskeip]

This definately improves things. I notice there are other cases in that function which have the same issue (stopping parsing strings at null), but I'm not sure if those are easy for users to call.

Same thing. Noticed that %G and %S got quite similar logic, but it seems like it's not a problem for the end user.

[ChrisJefferson]

In terms of printing out \0, I'm not opposed to this, but we already silently swallow many unprintable characters (we just send them for printing, and nothing gets displayed), it's just that \0 was causing problems as it's treated as end of string.

[fingolfin]

Regarding other format specifiers:

• %S is not used (anymore), and anyway it takes a zero-terminated string, so no need to worry about that
• %G and %C are used, but only by gac, the GAP-to-C-compiler -- each once:

    Emit( "%c = MakeString( \"%C\" );\n", string, str);
...
            Emit( "NameFunc[%d] = MakeImmString(\"%G\");\n", i, n );

The latter two are specifically used to sanitize valid GAP strings into a format that can then be re-read by a C compiler... and looking at it, I don't think either is implemented correctly (or alternatively: neither is suitable for what 'gac' uses it). So instead we should probably only retain %C (and drop %G and %S), and fix %C to do the right thing in all cases; which is to either escape low-value bytes into suitable C escapes (using octal or hex notation?), or to reject any of those.

Assuming we "fix" %C to handle any chars, I would look at SPECIAL_CHARS_VIEW_STRING in the GAP library to decide how to handle them; and I would add a test to tst/test-compile which involves compiling code that involves a string constant as generated by List([0..255],CHAR_INT);; and possibly some functions with "evil" names...

Actually there are more pitfalls there: one could e.g. define a unary function function( x\,y ) end where the single argument has a comment in its name. I am pretty sure that will confuse gac, too, because it uses ArgStringToList -- luckily there is a simple fix: don't emit code using ArgStringToList, instead emit a combination of MakeImmString and NewPlistFromArgs.

Anyway, this all goes way beyond this PR. I'll submit a PR of my own addressing some of these.

[fingolfin]

I've now made PR #5556 motivated by this one here.

[fingolfin]

Thanks, @nskeip !