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: On Unix-like platforms, this change should not cause any problems nor require any actions from you. On Windows, the easy solution is using a different installation directory for the new version, or to remove 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: procedure test; cdecl; ... exports test; in a library used to always export that procedure 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 platforms.
• Remedy: If you need a particular export name, use the test name 'sometestname'; export syntax.

Exporting library variables and functions

• Old behaviour: All publicly visible procedures, functions and variables in units used by a library were automatically exported by that library on Unix-lke systems.
• New behaviour: Only those procedures, functions and variables appearing in the exports section of a library are now exported.
• Reason: The old behaviour polluted the symbol namespace too much, and caused many more symbols to be exported than what was intended (such as the entire FPC run time library).
• Remedy: Add the names of the procedures, functions and variables you want to export to the library's export statement. Note that at this time, variables can only be exported using a name with which they were declared.

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 ifdefs 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.

Unhandled exceptions on Mac OS X/Intel (run time error 207)

• Old behaviour: Previous FPC versions did not enable arithmetic exceptions for the SSE unit of Intel Macs. This SSE unit is used by most of the system libraries to perform floating point calculations. This means that floating point errors in the system libraries were silently ignored (just like they are for C programs, as these exceptions are disabled there by default as well).
• New behaviour: FPC now enables all SSE floating point exceptions at startup. The result is that some (mostly GUI) applications now terminate with a "run time error 207".
• Reason: The FPC programming model includes reporting all floating point exceptions as they happen. Many existing programs expect this, since this is also the behaviour on other platforms.
• Remedy: Add the math unit to your uses clause and add the following statement at the beginning of your program: SetExceptionMask([exInvalidOp, exDenormalized, exZeroDivide, exOverflow, exUnderflow, exPrecision]). Note that this will disable floating point exceptions in all code, not just in the system libraries. The reason this is not necessary on PowerPC is that the macpas unit, which is automatically included in any program using one of the Common Pascal Interfaces units such as MacOSAll, already contains code to disable the exceptions for PowerPC. Similar code for Intel will be added to that unit in a future release, so you will not have to add it yourself anymore (see http://bugs.freepascal.org/view.php?id=11516).

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.