because on win64 the location of a function result can depend on its
size (so some chararrays had to be returned in registers and others
by reference, which means it's impossible to have a generic function
declaration which works in all cases) (mantis #8533)
* pad constant string assignments to chararrays with #0 up to the
length of the chararray for 2.0.x compatibility (fixes
tests/test/tarray3)
git-svn-id: trunk@6915 -
array[0..1023] into array[0..0], because they're used as
dummy return types for the Xstring_to_chararray helpers,
and if a smaller array is actually passed as result then
having a larger array declared will cause -gt to
overwrite other data
git-svn-id: trunk@6855 -
allow runtime optimization if the destination is the
same as a source parameter
* tassignmentnode now sets aktassignmentnode global that can be used
to use the left node as a destination parameter and
skip the assignment
* disabled all cpu specific shortstr concat/append
git-svn-id: trunk@4770 -
and 4080. The compatibility differences are:
a) writing a chararray which is zero-based but not zero-
terminated does not cause a buffer overflow
b) non-zero-based chararrays can also be read
The difference was that previously, all chararrays were treated
as pchars. In TP/Delphi (and now also in FPC), this is only done
for zero-based chararrays. For non-zero-based ones, the entire
contents of the array should always be used (including #0's).
The default parameters in the system unit for the chararray
helpers are to avoid having to use a define for bootstrapping.
git-svn-id: trunk@2152 -
and also have full double support (exp() only has support for values in
the single range in genmath, for example). Used in FPC_USE_LIBC is
defined
* several fixes to allow compilation with -dHASINLINE, but internalerrors
because of missing support for inlining assembler code
