Hashtag # in a string causing EOF?

[David Healey]

@ustk Did you edit the script in an external editor?

[ustk]

@David-Healey I probably did... or Claude did once or twice

[David Healey]

@ustk Might have added in some hidden characters

[ustk]

@David-Healey Claude found it's a parsing issue with double backslash escape that de-sync the parsing:

const var PATH_SEPARATOR = Engine.getOS() == "OSX" ? "/" : "\\";

That "\\" is a perfectly valid HISEScript string (one escaped backslash). But HISE preprocesses every script through the SNEX preprocessor before the JS compiler sees it, and that preprocessor has a buggy string scanner (snex_jit_PreProcessor.cpp:594):

// it only treats a backslash as an escape when the NEXT char is the quote:
if (*start == '\\' && *(start + 1) == quoteChar) { start += 2; continue; }

Walking "\\": it reads the first \, then sees the second \ sitting right before the closing " and concludes the " is an escaped quote — so it keeps scanning past the end of the string, swallowing text until the next " somewhere later. From that point on, the preprocessor's idea of "inside a string / outside a string" is inverted for the rest of the file.

Why single quotes fix it, and why it's specific to this script:

• Line 4's trap flips quote-phase for everything after it. Approaching line 443, the preprocessor wrongly believes it's inside a string.
• With '#': the ' and # are just harmless characters inside that (phantom) string → no problem.
• With "#": the first " closes the phantom string → the preprocessor is now "outside" → it sees a bare #, which it treats as a preprocessor directive marker (#define/#if/…). It grabs #" + i;, fails to match a directive, blanks the block, and the mangled leftover reaches the JS tokenizer → its JSON-based string parser hits EOF mid-string → "Unexpected EOF in string constant".
• It's confined to this file because the preprocessor runs per-file, and this is the file that contains both the "\\" trap and a #.

I proved it: replacing line 4's "\\" with the equivalent "\u005C" (same backslash, but no \\ right before the quote) makes the "#" version compile with zero errors.

Fix options
Recommended — remove the landmine. Change line 4 to a form that doesn't put \\ against the closing quote, then # works anywhere (double-quoted included):

const var PATH_SEPARATOR = Engine.getOS() == "OSX" ? "/" : "\u005C"; // backslash; avoids preprocessor quote-desync

[David Healey]

@ustk So why did the example in your first post fail?

[ustk]

@David-Healey because I had this in the same script

const var PATH_SEPARATOR = Engine.getOS() == "OSX" ? "/" : "\\"; // last " is escaped

const var someStringWithHashtag = "#"; // the first " closes the above line, so # is in the wild...

and the parser sees the second \ as an escape for the next char, which is ", hence messing the double quotes count.
Ii is not seen as an error until the parser sees a # which instead of being taken as string, is taken as a preprocessor call.

[David Healey]

@ustk Aha now it makes sense

[David Healey]

@ustk btw, HISE automatically uses the correct path separator if you use the File/FileSystem APIs.

[ustk]

@David-Healey Yeah I needed it for visual meaning in a label so Win users aren't lost

[dannytaurus]

@ustk Fable made a bug fix PR for this, so you can continue using "\\" as normal.

https://github.com/christophhart/HISE/pull/993

[ustk]

@dannytaurus Fabulous Fable!