jacksondunstan / UnityNativeScripting

Unity Scripting in C++

Home Page:https://jacksondunstan.com/articles/3938

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

String Injection Silent Fail

mthamer opened this issue · comments

This is great stuff, thank you!

One thing that bit me for a while, was that the code generation didn't seem to be working. I assumed I was doing something wrong in NativeScriptTypes.json which was causing a problem, but that turned out to not be the case. After debugging the GenerateBindings.cs code, I eventually realized it was silently failing to inject any changes because the line endings on the generated bindings files (cpp,h,cs) had changed to windows format (CRLF). This caused the GenerateBindings code to fail to find the markers it was looking for, when it went to inject modified code. For example, it looks for this marker in bindings.h:
"/BEGIN TYPE DEFINITIONS/\n"
but in my case, that was not found because the line endings were changed to this:
"/BEGIN TYPE DEFINITIONS/\r\n"

I was able to fix the problem by simply changing the line endings back to unix (LF) instead of CRLF, but a better solution might be to ignore or remove unwanted whitespace from the contents of the bindings files, before doing the string compares. Another option might be to remove the \n from the marker string that you are checking for.?
This could probably be chalked up to 'user error', but I'm afraid that others on Windows could easily encounter this problem as well, so making it a bit more bullet-proof would help.

See below for the area of the code I am referring to.

Thanks again!
-Mustafa

GenerateBindings.cs : line 13511
static string InjectIntoString(
string contents,
string beginMarker,
string endMarker,
string text)
{
for (int startIndex = 0; ; )
{
int beginIndex = contents.IndexOf(beginMarker, startIndex);
if (beginIndex < 0)
{
// EXTRA LOGGING CHECK
if (startIndex == 0)
{
Debug.Log("InjectIntoString: Nothing injected, failed to find beginMarker:" + beginMarker);
}
// END EXTRA LOGGING
return contents;
}
...

Hey Mustafa,

I'm glad you're enjoying the project! I've previously thought that changing the line endings, or anything else, in the generated files should be considered off-limits, but this is the second report of issues with just line endings which may be converted automatically by a text editor just when opening the file to read it or by a version control system attempting to normalize across OSes. It should be relatively easy to work around the issue, as you point out, so I marked this as an enhancement and hopefully I'll get around to implementing it soon. If you want to implement it sooner, feel free to send me a PR.

Best,
-Jackson