Since overloading compilerprocs does not work each procedure got its own unique name, but they are using the new compilerproc extension to map them to the Insert and Delete symbol so that error messages can be shown with the respective name for the procedure declarations instead of fpc_shortstr_delete for example.
git-svn-id: trunk@33895 -
o removed utf8string overload
o always ignore any code page information from the input, and interpret the
contents of the input directly as utf8-encoded bytes
* made utf8tostring() compatible with the JVM backend (mantis #29497)
git-svn-id: trunk@33159 -
RTL units. Comes with a FPCRTL_FILESYSTEM_UTF8 define that can be
activated for targets whose single byte filesystem interface enforces
UTF-8; included in inc/systemh.inc and unix/cwstring.pp until now
+ DefaultFileSystemCodePage variable that holds the code page used for
communicating with the OS single byte file system APIs, and for the
strings returned by those same APIs. Initialized with
o the result of GetACP in the system unit of Windows platforms, except for
WinCE which uses UTF-8 since its file system OS API calls already use
the UTF-16 versions
o CP_UTF8 on Unix platforms with FPCRTL_FILESYSTEM_UTF8 defined, and with
DefaultSystemCodePage on other Unix platforms
o DefaultSystemCodePage on Java/Android JVM targets
+ DefaultRTLFileSystemCodePage variable that holds the code page used to
encode strings returned by RTL routines that return filenames obtained
from OS API calls. By default the same as DefaultFileSystemCodePage on
all platforms. Separate from DefaultFileSystemCodePage for clarity on
platforms that may use either utf-16 or single byte OS API calls to
send/receive file names (such as most Windows platforms)
+ new scpFileSystemSingleByte enum that can be passed to
GetStandardCodePage() to get the default code page for OS single byte file
system APIs, with implementations for Unix and Windows
+ SetMultiByteFileSystemCodePage() procedure to override the value of
DefaultFileSystemCodePage
In principle, in the long run unchanged programs only using generic
ansistrings and unicodestrings should (mostly) behave the same as in
FPC 2.6.0 as far as RTL-level file system APIs are concerned if
they set DefaultFileSystemCodePage and DefaultRTLFileSystemCodePage
to DefaultSystemCodePage at the start of their execution
git-svn-id: branches/cpstrrtl@22466 -
o support for the new codepage-aware ansistrings in the jvm branch
o empty ansistrings are now always represented by a nil pointer rather than
by an empty string, because an empty string also has a code page which
can confuse code (although this will make ansistrings harder to use
in Java code)
o more string helpers code shared between the general and jvm rtl
o support for indexbyte/word in the jvm rtl (warning: first parameter
is an open array rather than an untyped parameter there, so
indexchar(pcharvar^,10,0) will be equivalent to
indexchar[pcharvar^],10,0) there, which is different from what is
intended; changing it to an untyped parameter wouldn't help though)
o default() support is not yet complete
o calling fpcres is currently broken due to limitations in
sysutils.executeprocess() regarding handling unix quoting and
the compiler using the same command lines for scripts and directly
calling external programs
o compiling the Java compiler currently requires adding ALLOW_WARNINGS=1
to the make command line
git-svn-id: branches/jvmbackend@20887 -
This change is required since CodePage to CodePage name conversions are required in other parts of RTL. Moreover those codepage identifiers are windows codepage identifiers and thus must be compatible with codepage identifiers used by delphi.
git-svn-id: trunk@19330 -
rtl: change UTF8Decode, UTF8Encode, AnsiToUTF8, UTF8ToAnsi to use RawByteString as arguments/result for compatibility with the old code and also with delphi
git-svn-id: trunk@19128 -
- fix return type of StringCodePage functions from Word to TSystemCodePage
- add SetMultiByteConversionCodePage procedure (which just change the DefaultSystemCodePage constant)
git-svn-id: trunk@19095 -
- a set of rtl changes from AnsiString to RawByteString to various conversion functions
- a test which proves output in cp1251 and cp866 codepages (standard for Russian windows)
git-svn-id: trunk@19093 -
+ Win32Unicode2AnsiMove and Win32Wide2AnsiMove support code page parameter
+ Win32Ansi2UnicodeMove and Win32Ansi2WideMove support code page parameter
+ code page parameter added for several compilerprocs
* unified more code between win32 and win64 (widestring conversion routines
git-svn-id: trunk@19082 -
+ support parsing of strings with code page specification
+ added encoding and elementsize field to ansi- and unicodestring records
+ some basic rtl support routines for encoding aware strings
+ DefaultSystemCodePage
+ DefaultUnicodeCodePage
+ ppu writing/loading of code page aware strings
git-svn-id: trunk@19080 -
val/str for enums for now) for the JVM target: insert/delete/pos/...
* use generic unicodestring helper routines where possible for the JVM
target (not that many as for shortstrings since unicodestring is
handled using java.lang.String)
+ complete widestring manager implementation for the JVM target. It uses
a class with virtual methods rather than a record with function pointers
for speed reasons though (since no existing widestring manager will be
compatible anyway, that shouldn't cause any problems)
git-svn-id: branches/jvmbackend@18882 -
consistency with other helpers
+ added lowercase(unicodechar) and lowercase(unicodestring) overloads (for some
reason only upcase() existed for them)
git-svn-id: branches/jvmbackend@18881 -
determine the length of a multi-byte character. The return values
are defined to be the same as those of POSIX' mblen: -1 =
invalid/incomplete sequence, 0 = #0, > 0 = length of sequence in
bytes.
+ default implementation for widestringmanager.codepointlengthproc
(assumes all code points have length 1) and Unix implementation
(based on mb(r)len); Windows implementation is still required
* replaced default implementation of
widestringmanager.CharLengthPCharProc with strlen() of the input
instead of an error (correct if all code points have length 1,
still needs Windows implementation)
+ implemented fpc_text_read_{wide,unicode}str() and
fpc_text_read_widechar() (mantis #18163); fpc_text_read_widechar()
uses the new widestringmanager.codepointlengthproc()
+ unicodestring support for readstr/writestr
* fixed declaration of fpc_Write_Text_UnicodeStr (unicodestring
instead of widestring parameter)
* extended test/twide*.pp tests to test the new/fixed functionality
git-svn-id: trunk@16533 -
