I was doing some feature hacking on @RockstarLang last night and hit one of the weirdest bugs I've seen in... a long, long time. Finally figured out today what was causing it.

So: in Rockstar, you can initialise a string literal using the "says" keyword:

Foo says hello world

The variable Foo now contains the string literal "hello world". It's matched using a PEG syntax patterns that looks for the "says" keyword and then captures everything up to \\n. The grammar is actually pretty simple.

So... last night I'm testing something like

Foo says hello
Bar says world
Shout foo with bar

Expecting to get "helloworld"

But no. Just "world". Strange. I start digging.

The parse trees are correct. The expressions are correct. The values are correct - foo is definitely "hello", bar is definitely "world". I try some other values... this is where it gets WEIRD.

Foo says goodbye
Bar says world
Shout foo with bar

I run this... It prints "worldye"

Now, a few days back I added a feature to shallow-copy arrays so you can pass them by reference into Rockstar functions. And I'm thinking "I must have screwed up the array assignment code or something." I roll back a few commits. The bug is still there. This is REALLY REALLY odd.

Nothing is wrong. The code is correct. The variables are correct. The parser, the interpreter, are all working absolutely fine. But:

Foo says apple
Bar says banana
Shout foo with bar

is still printing "applea"

Have you figured it out yet?

You see... the bulk of the initial Rockstar development was done on macOS. \\n line breaks. But these days I'm doing most of my work on Windows. \\r\\n line breaks.

Foo says apple

Is actually

Foo says apple\\r\\n

So the parser captures everything up to the \\n - INCLUDING THE \\r...

You know what happens if you print a carriage return with no line feed to a text mode terminal? It moves the cursor back to the start OF THE SAME LINE and starts overprinting what was there before.

So it prints "hello", returns to the start of the line, prints "world" over it.

But of course, \\r is invisible. So it won't show up in a console.log or any other operation that implicitly adds a new line to end of the output.

Turns out that, although the PEG grammar explicitly defines an EOL to be \\r?\\n, this particular rule was using a hard coded \\n. D'oh.

And this particular edge case wasn't covered by any of the test cases. Double d'oh.

So, yeah. 50 years since ASCII and we still get messed up by something as simple as how to end a line of text.

Interesting, though.

OK, history lesson time. The reason for this particular idiosyncrasy: modern macOS evolved from Unix, which evolved from Multics, which was one of the first operating systems to implement the idea of a device driver.

Because Multics used a software abstraction layer between the operating system and the physical hardware, it was trivial to translate the logical \\n line feed into the appropriate set of physical instructions for the terminal device or teleprinter that was in use.

If you were using a mechanical teleprinter that required a separate carriage return operation and line feed operation, that was the teleprinter's problem; it was no longer something you needed to explicitly include in your text files and ASCII streams.

Windows 10, on the other hand, evolved from Windows 7, which evolved from Windows NT, which evolved from Windows 95... all the way back to MS/DOS. Which was hevily influenced by Digital Research's CP/M, which incorporated a lot of ideas from mainframe terminal systems.

And because mainframes were - and are - normally specific hardware running a specific operating system, from a single vendor, they never really got into the idea of device drivers. When you control the hardware and the OS, it's easier just to talk to the hardware directly.

So, there you go. A weird bug in an esoteric language in 2020 that you can trace all the way back to mainframe hardware architecture vs Multics device drivers in the mid 1960s.