[I6] Newlines in Z-Machine vs Glulx

I noticed that the characters used for new lines in Z-Machine and Glulx are different. I mean, when you write it in the code, it’s all “^”, but when for instance you use print_to_array, this character is translated differently if you’re in Zcode or in Glulx. (I’m not sure, but from what I understand, print_to_array is basically doing “@output_stream 3, print, @output_stream -3”, so maybe the translation occurs in the print statement).

In Z-Machine, the newline is character n°13, which is a carriage return (’\r’). In Glulx, the newline is character n°10, a line feed (’\n’).
I see on Wikipedia that it’s a non-standardized/controversial thing (that’s why Unix files look like a single line on Windows Notepad). It makes sense that the Z-Machine was using \r, since it was the norm on ZX Spectrum, C64, Apple II, etc (although how did they do it for Amiga or DOS? Was there a terp hack that replaced 13 by 10?). And Glulx only follows the Unix convention.

This looks like it’s a problem in other areas of computing, so it’s not like it’s an error or a bug; but it’s annoying that it’s one of the only characters that can’t be put in source and it is translated by the compilers differently.
I had this problem occur because I have code that manually prints each character from a string and was looking to handle “^”; but I don’t think I can write

         if (c == '
') { ... }

and it’s ugly anyway. (If it was any other character, like accented letters, who also have different translations in Zmachine and Glulx, I could write “if (c == ‘é’)” and it’d be bi-platform.) So instead I write

#Ifdef TARGET_ZCODE;
     if (c == 13) {
#Ifnot; ! TARGET_GLULX
     if (c == 10) {
#Endif;

which isn’t the most graceful and requires commenting. I don’t know if this warrants a bug report, but it’s quirky (and is mildly annoying), so I don’t really know what can be done about it :slight_smile: I really have no idea how it could be ‘fixed’ either.

Correct. You’re also correct that it isn’t going to change.

Your solution is fine. You could also define a constant at the top level:

#Ifdef TARGET_ZCODE;
Constant NEWLINE 13;
#Ifnot; ! TARGET_GLULX
Constant NEWLINE 10;
#Endif;

It would be possible to define a new character escape for this (perhaps “@nl”?) but I’m not sure there’s that much need.

Please add the new character escape. I guess I could add it and send in a pull request, but I don’t clearly see how to fit it into the default_zscii_to_unicode_c01[] table.

I’ll add the ifdefs to the Library.