User Changes 2.2.2

About this page

Below you can find a list of intentional changes between the the 2.2.0 release and the 2.2.2 release which 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

Char to WideChar conversions and vice versa

• Old behaviour: Type conversions between chars and widechars did not cause any translations of the data.
• New behaviour: A char to a widechar conversion or vice versa now triggers the widestring manager, and converts the data from ansichar to widechar or the other way around. If a converted widechar is not representable in a single char, the result of the conversion is always '?'
• Example: char_var:=char(widechar_var); used to put the lower 8 bits of widechar_var into char_var, while now the widestring manager is called to translate widechar_var from UTF-16 to the active code page.
• Reason: Bug report 7758, and consistency with conversions between shortstrings/ansistrings and widestrings.
• Effect: If you previously typecasted chars to widechars or the other way around (possibly via parameter passing or assignments), these type conversions will now cause the data to be translated.
• Remedy: If you do not want any translation to be performed, add an additional type conversion to an integer type in between, e.g. char_var:=char(word(widechar_var));

Typecasting ordinal constants to complex types (records, arrays, sets)

• Old behaviour: It was possible to typecast ordinal constants into records/sets/arrays at compile time.
• New behaviour: Such type casts now always give a compile time error.
• Example: type tr = record a,b,c,d: byte end; ... writeln(tr($12345678).b); use to be accepted by the type checking code, but now it isn't anymore.
• Reason: Many parts of the compiler could not really deal with this sort of code and either generated wrong code or caused internal errors. This sort of code is not allowed by Delphi either.
• Remedy: Assign the value first to an ordinal variable of the appropriate type and then perform the type cast using this variable.

Internal format of sets

• Change: The internal storage format of sets has been changed compared to earlier versions of FPC. Both the size and the content of sets can be different in FPC 2.2.2 compared to what they were before.
• Reason: Store sets in less space, Delphi compatibility.
• Remedy: If you have binary files containing sets which you would like to convert to the new format, you can use the setconv unit available from the FTP site. This archive also contains an example on how to use it.

Restructuring of packages

• Change: FPC packages have been restructured and some units are installed in different directories than in the past. If trying to overwrite an older version with the new one by installing the new version into the directory previously used for the older version, old units may be left on your disk and FPC may potentially find the wrong (old) version of these units.
• Reason: The new structure allows easier maintenance and use of the coming package manager.
• Remedy: Easy solution is using a different directory for installation of the new version or removing the existing installation first if you want to use the same directory for the new version. If this is not possible, you can always locate older units by looking for .ppu,.o and possibly .a files built earlier than in year 2008.

All Unix-like systems

Name mangling of exported library functions

• Old behaviour: If no export name was specified, the identifier as it appeared in the source code was used as exported name
• New behaviour: If no export name is specified, then
  • If the routine is declared using the mwpascal or cdecl calling convention, the exported name will be mangled like a C compiler on the target platform would do;
  • If the routine is declared using the cppdecl calling convention, the exported name will be mangled like a C++ compiler on the target platform would do;
  • Otherwise the old behaviour is kept.
• Example: function test; cdecl; ... exports test; in a library used to always export that function as test. Now it will be exported as _test on unix-like platforms where C compilers implicitly add an underscore to all global symbol names (such as Mac OS X).
• Reason: This avoids the requirement to use ifdefs to support proper exporting of cdecl routines from Pascal libraries to C programs on different programs.
• Remedy: If you need a particular export name, use the function name 'somename'; syntax.

Mac OS X

FPCMacOSAll unit

• Old behaviour: The included Common Pascal Interfaces unit containing all translated APIs was called FPCMacOSAll.
• New behaviour: This unit is now called MacOSAll.
• Reason: The Common Pascal Interfaces can be used with FPC, GPC and MW Pascal. Since the FPCMacOSAll, GPCMacOSAll and MWMacOSAll units all included basically the same functionality, the different names required useless ifdef's in programs compilable with several of these compilers.
• Remedy: Replace uses FPCMacOSAll with uses MacOSAll. You can protect this change with {$if not defined(VER2_2_0) and not defined(VER2_0_4)} for backwards compatibility purposes.

WinCE

Windows unit

• Old behaviour: All WinCE API interfaces were contained in the Windows unit.
• New behaviour: The Windows unit contains only the basic API interfaces. Other API interfaces are contained in separate units like aygshell, commctrl, shellapi, etc.
• Reason: Make the WinCE unit names consistent with the Win32/64 unit names.
• Remedy: Add additional units to uses clause to fix compile time errors. You can protect this change with {$ifndef VER2_2_0} for backwards compatibility purposes.