This library having been developed on Linux is not aware of datatypes on other platforms. In any case, simply commenting out the definition in UTF8.bi will not be the solution, unless the definition is identical (zstring ptr). On Windows one solution would be to rename PCHAR (and PCCHAR) in UTF8.bi and UTF8.bas. The datatype was named after and to mimic Pascal's PCHAR as the library was partially translated from the Lazarus project.
UTF-8 Variable Length String Library
Re: UTF-8 Variable Length String Library
Re: UTF-8 Variable Length String Library
Yes, he was right. I included your header together with windows.bi. Linux already speaks UTF-8 natively so I think there is no need for an UTF-8 library for it. Windows on the other hand really needs such library since it speaks UTF-16 and expects UTF-16.Munair wrote: ↑Apr 05, 2022 5:37This library having been developed on Linux is not aware of datatypes on other platforms. In any case, simply commenting out the definition in UTF8.bi will not be the solution, unless the definition is identical (zstring ptr). On Windows one solution would be to rename PCHAR (and PCCHAR) in UTF8.bi and UTF8.bas. The datatype was named after and to mimic Pascal's PCHAR as the library was partially translated from the Lazarus project.
BTW, I think the definition is equivalent. On the Windows API pchar is char* which is the same as zstring ptr.
Re: UTF-8 Variable Length String Library
FreeBASIC has no string manipulation routines built in that support unicode. For example, taking the first 10 characters of a string with LEFT(text, 10) really takes the first 10 bytes, which means that if the string is UTF-8, the encoding may be broken (if a character takes up 2, 3 or 4 bytes). So this is not just about the platform supporting UTF-8, but also about manipulating unicode strings correctly in FB.