User Changes Trunk

About this page

Below you can find a list of intentional changes since the previous release that can change the behaviour of previously working code, along with why these changes were performed and how you can adapt your code if you are affected by them.

All systems

Usage Changes

Static keyword is enabled without switches and directives

Old behaviour: To allow use of 'static' keyword it was needed to pass the -St switch to the compiler or use {$STATIC} directive.
New behaviour: Usage of 'static'keyword is now enabled without switches or directives.
Effect: -St switch is deprecated and {$STATIC} directive does not exists anymore.
Reason: There is no reasons in the switch/directives after compiler restrictions were added to reject fields after methods in the class/object declaration. And moreover recent versions of delphi implements 'static' class method support.
Remedy: Adjust your build scripts and code to remove -St and {$STATIC} from them.

Language changes

Passing derived classes to var- and out-parameters

Old behaviour: If a routine was declared with a var- or out-parameter of a certain class type, the compiler also allowed passing derived classes to this parameter.
New behaviour: The compile-time type of a class passed to a routine now has to match the declared parameter type exactly in case of var- and out-parameters.
Example:

<delphi> {$mode objfpc}

type

 ta = class
 end;

 tb = class(ta)
 end;

var

 b: tb;

procedure test(var a: ta); begin

 a:=ta.create;
 // now b contains an instance of type "ta"

end;

begin

 b:=nil;
 test(b);

end. </delphi> The compiler used to accept the above program, but now it will give an error at the call to test.

Reason: As the example above demonstrates, allowing this behaviour circumvents the language's type checking. This change is also Delphi-compatible.
Remedy: Rewrite the affected code so it that all var/out-parameters and the class types passed to them match exactly. There are ways to circumvent the type checking at the caller side by using explicit type conversions, but using such hacks is strongly discouraged since the resulting code is not type-safe.

Array of const parameters and cdecl routines

Old behaviour: It was possible to have non-external cdecl routines with an array of const parameter.
New behaviour: Cdecl routines with an array of const parameter now always must be external.
Reason: In FPC, adding an array of const parameter to a cdecl routine has the same effect as adding the varargs modifier. It means that the routine takes a C-style variable number of arguments. There is however no way in (Free) Pascal to access these arguments on the callee side. This change means that both varargs and array of const are treated consistently, since varargs routines already had to be external.
Remedy: Remove the cdecl specifier and use a Pascal-style array of const, or implement the routine in C and add external to the Pascal declaration.

String constants longer than 255 chars

Old behaviour: String constants longer than 255 chars were silently cut off after 255 chars under certain circumstances.
New behaviour: String constants longer than 255 chars cause an error in $H- state, in $H+ state an ansistring constant is generated.
Reason: Cutting of strings silently sounds like bad behaviour of the compiler.
Remedy: Manually truncate string constants longer than 255 chars or use $H+

Implementation changes

Order of parameters in RTTI

Old behaviour: The order in which the parameter information for a function was stored in the RTTI depended on the function's calling convention. If the calling convention on i386 passed parameters from left-to-right, parameters were stored from left to right (regardless of the actual platform, which was a bug in itself), otherwise they were stored from right to left.
New behaviour: The parameters are always stored from left to right in the RTTI, i.e., as they appear in the source code.
Effect: Code parsing RTTI information for the purpose of figuring out in which order to pass the parameters will no longer work.
Reason: Delphi compatibility, making the information more useful for IDEs.
Remedy: Adjust your code so it always expects parameters to appear in the RTTI ordered from left to right. In the future, we will also add the calling convention itself to the RTTI (like Delphi), so you can use that information to reorder the parameters in case you want to use this information to call the routine.

Sizes of sets in TP/Delphi mode

Old behaviour: {$packset fixed} was the default for all language modes. This packs a set of up to 32 elements in 4 bytes, and all other sets in 32 bytes.
New behaviour: The default in TP/Delphi mode is now {$packset 1}
Effect: In those language modes the size of sets with 1..8 elements will now be 1 byte, and the size of sets with 9..16 elements will be two bytes. Sets with 17..32 elements will remain 4 bytes, but after that every additional 8 elements the size will increase by 1 byte up to 249..256 elements, which will result in a set of 32 bytes.
Reason: TP/Delphi compatibility.
Remedy: If you have code written in TP/Delphi mode that depends on the old packset setting, add {$packset fixed} to the source (after setting the syntax mode to Delphi/TP, since the mode switching changes the packset setting). This is backward compatible with at least FPC 2.2.4 and later.

Constants in mixed signed/unsigned 64 bit expressions

Old behaviour: Some comparisons involving a negative 64 bit constant and a unsigned 64 bit variable were handled incorrectly by the compiler: the negative constant was internally explicitly typecasted to the unsigned type.
New behaviour: The compiler will now correctly use the original value of the negative constant.
Effect: Some comparisons that previously evaluated to "true" at run time, may now evaluate to "false" at compile time.
Example:

<delphi> const

 // note that 64 bit hexadecimal constants are always parsed as int64
 // (also by previous FPC releases)
BIG_A = $AB09CD87EF653412;

var

q : qword;

begin

q := qword(BIG_A);
if (q = BIG_A) then
  writeln('same')
else
  writeln('different');

end. </delphi> The above program used to print 'same', but will now print 'different'

Reason: The compiler must not automatically convert negative constants to positive equivalents like that.
Remedy: Explicitly typecast any constants that are supposed to be unsigned 64 bit constants to qword. E.g., in the above example, use BIG_A = qword($AB09CD87EF653412).

Parameter passing and returning results on x86-64 platforms (except for Win64)

Old behaviour: The compiler did not correctly implement the official x86-64 ABI for passing parameters and returning function results in all cases. In particular, records were always either passed/returned via integer registers or memory.
New behaviour: The compiler now correctly adheres to the official x86-64 ABI under all circumstances on platforms that require this. In particular, certain records are now passed/returned via SSE registers.
Effect: Pure assembler routines based on the old conventions may no longer work on non-Win64 platforms. Win64 follows Microsoft's own variant of the x86-64 ABI and this one was already implemented correctly in the compiler, and hence has not been changed.
Reason: Interoperability with code generated by other compilers.
Remedy: Adjust your assembler code so it expects parameters to be passed conform to the official x86-64 ABI

Unit changes

==== xmlrpc unit and utils have been removed

Old behaviour: There was an unit xmlrpc and a demo program mkxmlrpc
New behaviour: These units have been removed in trunk, and deprecated in fixes.
Reason: Code was unmaintained and broken for years, and has been replaced by new functionality in fcl-web/fcl-json
Remedy: use fcl-web or, in dire cases, obtain the xmlrpc sources from older versions.

x86 platforms

Operation size of pushf/popf/pusha/popa in Intel-style inline assembly

Old behaviour: The default operation size of the pushf/popf/pusha/popa in Intel-style inline assembly was the native size (32 bit on i386, 64 bit on x86-64).
New behaviour: The default operation size of these opcodes is now always 16 bit in Intel-style inline assembly. In AT&T-style inline assembly, the size remains the native size.
Reason: This is how the behaviour of these opcodes is defined in the Intel manuals, and it is also Delphi-compatible. The behaviour was not changed in AT&T-inline assembly because that dialect defines the default size of these operations as the native size.
Remedy: Explicitly specify the size when using such operations, e.g. pushfd, popfq, pushad, ... Note that pusha*/popa* do not exist on x86-64, and neither do pushfd/popfd (the compiler previously however erroneously accepted these opcodes when compiling for x86-64).