Hashtag # in a string causing EOF?

[ustk]

That's because I needed '#' instead of "#"

[David Healey]

@ustk No error here

HiseSnippet 773.3ocsUstSZDDEdFj0TnWRMoO.Sr+Aql5BBVoTSsxkVREkTTSSLFyvryJSbYlMyNXkzz249FzdlcQ.qDuPRme.64x2Le6Y9NmssVw3QQJMBm8vggbD9YNcFJM8p1iJjnl0P3W3zhFY3ZRhqcGFRih3dHLdgOacfyjFEu98G2kFPkL9DWHzwJAiumnuvLwa3NeUDDzf5wOTzeprKtSSlRVUEnF.7YAGWTHkcA8b99TaZobPegF0CgeiS9h48bKUpKuPYe2M4ta3R8cKVfVtaYuhk3k4tdaUfybQ3Eq6ILJcGC0vifMcWk2vN8T+Plb.GKhDcC3Vi7nNvIm3FUsmHvq80EmHDBmt8jR0BIkpW4zR3IF6eRI6kwAHSPLcQCm5tnT9GAkvSQozITZImNLsHzLIhkOO0ooDtA8ovcyzTIIWTJI1opBxPZdae5E7FZvXLhba55tFA9YkJYyJjABIm3OPxLBkjHjBi8csZ2nbqj8mYIvJPwnADFaOQjgrM4jSAbV+9JMImXa2JDwGxWXK3uUWck3H1UR9mHNEfr7qWlrJQTgr95DtVqzumbjjeUHmY3dj5Gz.NWRjQKjmS.ESjgJMY+kkcSwlJiIoRtuxvOPFyvLPhj+Mju+LiYKJZUP.WOyvV0q9t.lSNneWtdMxkzfA7wIB2V2TBr3CSBvRtilJQkrI7JePHejcCUfm8p097sELnQWxvSG0rF0PsZnQ9f7B4ZivRGbM9kPWahhJiSMdzEFUHBca4FHzUdCBnlap9syEFE.pG2PxYkUxHgY3zyMdDsDt2YKwCkhK4zVXX8lMGSMCNBUp+Gbbzfjm6T22GD2SHXZmFeedmZbOG+2TCLPiSKJz+bEB6r+f9cfAtLNb5RIO.1bGbJqZIw10Zaq.c3RuXi+.qQAyaswiBl+5fn9TlVcFKoKvNp5Iwd.NIiGkmA9lBXSxih6LltN2G5eOiwt4VcKfElWfaLu.KNu.KMu.2bdA9t4E3V2OP630OMvn5mz1fPsZWOdTBFWWRAEXrZE8Wr5mNUF

[ustk]

@David-Healey Mmmm... That is very very strange. It effectively works on a new project on both mac and win but not in my current big project, and only in a specific place in code...
This reminds me of a missing " issue I heard of around here... Investigating...

[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