Compiler crashes when you includes an include with included another include with define with Russian string in it

[NexiusTailer]

The long name of this issue speaks for itself. Do not ask how I got to this point.

And this only works if you compile your script which includes an "include1" that includes an "include2" with a define with Russian-character string and uses it inside itself (ie if you try to compile "include1", then you will not get any errors).

Just look at the example with a few steps:

1. Create a file that will be named "include1.inc" in your include folder
2. Put this code in it and save:

#include <a_samp>
#include <include2>

forward SomeFunction();
public SomeFunction()
{
	print(SOME_STRING_DEFINE);
	return 1;
}

3. Create a file that will be named "include2.inc" in your include folder
4. Put this code in it and also save the file:

#define SOME_STRING_DEFINE	"Строка с русскими символами"

• (which is translated as "A string with Russian characters", actually nothing magical)

5. Ok, now open your main script (or just create new one) and include the "include1"

// This is a comment
// uncomment the line below if you want to write a filterscript
//#define FILTERSCRIPT

#include <a_samp>
#include <include1> // <- Here

main(){}

//Other stuff

6. And let's try to compile it, good luck

If (for some reason) you can't copy Russian text from the define, then I will attach the archive with all the necessary files and the latest version of Zeex's pawn compiler. You just need to try to compile "Untitled.pwn", which is in the folder "gamemodes".

Test.zip

P.s. File encoding of both includes: ANSI.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[NexiusTailer]

I don't think it should be closed so here it is some "activity". And also what about some confirmation or anything else that would be show the maintainers just didn't forget about this?

[Southclaws]

It won't be closed, that message is wrong, sorry.

As for maintainers, the team are just doing this in their spare time so things will only happen at a certain speed.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity.

[Y-Less]

So another issue on this determined that they were trying to use Unicode characters in a non-Unicode build of the compiler (i.e. Invalid characters). Is that the case here? Does it still happen when you set and use the correct code page?

[NexiusTailer]

So another issue on this determined that they were trying to use Unicode characters in a non-Unicode build of the compiler (i.e. Invalid characters). Is that the case here? Does it still happen when you set and use the correct code page?

Do you mean I should change the encoding of some of the files? Ok, I changed it to utf-8 (with some corrections of rewriting russian text as initially when changing the encoding its characters got lost) and it still hangs. Unicode doesn't seem to be supported by the pawno editor (or maybe even by the compiler too). Anyway all my scripts uses ANSI by default and I don't think this is the problem.

I think you should download the archive from the first post above (Test.zip), replace the compiler files with the latest ones and try to reproduce this problem yourself, if my answer isn't informative enough.

[AGraber]

@NexiusTailer just for the record, try using this (pawn compiler 3.10.9 built with NO_UTF) to see if it still happens

pawn-v3.10.9-no-utf8-windows.zip

[NexiusTailer]

@AGraber yeah, now it goes without crashes and works properly, but only with this build.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity.

[NexiusTailer]

I recently remembered this issue and now really wondered why this problem doesn't occur on the "no-utf8" version and why the main version still has this problem if a solution has been found?

[AGraber]

I think the reason why it crashes is that the compiler attempts to interpret text outside the ASCII standard table (> 127) as UTF-8, but fails to do so properly and crashes. Building the compiler with the "NO_UTF8" definition skips everything UTF-8 related, so it reads the text "as-is", without trying to do anything funny.

[NexiusTailer]

And what about some fix that could possibly be included in the main release? Or is it just not worth it and people with such problems should use a different version of the compiler each time?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity.

[Y-Less]

And what about some fix that could possibly be included in the main release? Or is it just not worth it and people with such problems should use a different version of the compiler each time?

The fix should be included.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity.

[ukenjutsu]

Still not fixed in the current compiler version (3.10.10)