Yes, code-points, what else. It corresponds to this 4-days-words-thread, but

after Tomasz's fantasy had explicitly refunctionalized ( and that is a good sign)
the ISO concept of codepoints i meant, there's no need to seek for explanation for at least a couple of days.

you are a Sexy-Girl in my imagination.
anyway, very few UltraIde-S or Notescratch-Es will represent -by glyphs-
codepoints and bidi infos correctly without using a clever/complex algo/work.
Besides, programs cannot compile mixed code as in the picture
(arab code+english code) without a rule, a standard that doent rely
obviously on the visualization.

The matter is that apparently (or actually) there is no need to implement
in fasm the basic feature of eating UTF-16 codepoints au lieu de 8bit chars.

1) you read it ?
yes ? ok, this is 50% the purpose.
2) would you like to compile that code with fasm as you see/read/modify it ?
Yes ? but there's no need to do it! yes again ?
also, a standard is required.

Cheers,
hopcode

btw: this sample code useful, cum grano salis

instead of

...because imho negative returning to the caller is not the best
disposition to bring a new way of thinking nearer.

hopcode: I still don't get what you are suggesting. Your responses are vague and unclear.

Do you want your new version of fasm to be able to compile the ASCII/Arabic example?

Why have two copies of the same code?

What if the two copies are inconsistent with each other?

Who can be bothered to write two versions of everything anyway?

Why do you suddenly mention about negative/positive return values? What has the '-1' return value got to do with UTF-16 encoded files?