Difference between revisions of "User Changes Trunk"

From Lazarus wiki
Jump to navigationJump to search
(+ MacOSAll unit: changed parameter and opaque types)
Line 178: Line 178:
 
== Other ==  
 
== Other ==  
  
=== upx support has been removed ===
+
=== UPX support has been removed ===
* '''Old behaviour''': There were some leftover of dos times upx support in the makefiles, and dos and windows versions came with an upx.
+
* '''Old behaviour''': There was some leftover UPX (an executable packer) support in the FPC Makefiles, and DOS and Windows FPC releases included an UPX binary.
 
* '''New behaviour''': All removed.
 
* '''New behaviour''': All removed.
* '''Reason''': Release binaries haven't been upxed for a while.
+
* '''Reason''': Release binaries haven't been UPX'ed for a while. The size of the FPC executables is generally insignificant these days compared to the total installation size, and using UPX occasionally causes some minor annoyances (false positives from virus scanners, worse paging behaviour by the OS, incompatibilities with certain executable sections, ...)
* '''Remedy''': Use 3rd party upx tools
+
* '''Remedy''': Download and install UPX yourself from its [http://upx.sourceforge.net/ homepage].
  
 
== See also ==
 
== See also ==
 
* [[FPC New Features Trunk]]
 
* [[FPC New Features Trunk]]
 
[[Category:FPC User Changes by release]]
 
[[Category:FPC User Changes by release]]

Revision as of 13:15, 1 November 2012

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. The list of new features can be found here.

All systems

Unit changes

FileNameCaseSensitive and FileNameCasePreserving in unit System

  • Old behaviour: There was only one constant (FileNameCaseSensitive) which signalized behaviour of the respective target platform with regard to the case in filenames. This was often set to true also on platforms not really treating filenames in case sensitive manner (e.g. Win32 and Win64).
  • New behaviour: FileNameCaseSensitive is set to true only on platforms which really treat filenames in case sensitive manner and FileNameCasePreserving constant is added to unit system of all platforms to signalize whether the case in filenames supplied when creating or renaming them is preserved or not. This might possibly break existing user code relying on the previous (sometimes incorrect) value of FileNameCaseSensitive.
  • Reason: In reality, there are two distinct types of behaviour. If a platform is case sensitive, searching for file "a" will never result in finding file "A" whereas case insensitive platform will happily return "A" if such a file is found on the disk. If a platform is case preserving, it will store file "a" as "a" on disk whereas case non-preserving platform may convert the filenames to uppercase before storing them on disk (i.e. file "a" is in reality stored as "A"). Case non-preserving platforms are never case sensitive, but case preserving platforms may or may not be case sensitive at the same time.
  • Remedy: Review your existing code using FileNameCaseSensitive, check which of the two properties described above fit the particular purpose in your case and change to FileNameCasePreserving where appropriate.

Several methods of TDataset changes signature (TRecordBuffer)

  • Old behaviour: Several (virtual) methods of TDataset have parameters of type "pchar", which are often called "buffer".
  • New behaviour: The pchar type has been changed to TRecordBuffer. Currently this type is still an alias for p(ansi)char, but in time it will be changed to pbyte for the 2.7.1/2.8.0 branch, which is D2009+ compatible.
  • Reason: Preparation for Delphi 2009+ compatibility and improving of general typing. In Delphi 2009+ (and fully compatible FPC modes in the future) pchar is not pointer to byte anymore. This change will be merged back to 2.6(.2), but with TRecordBuffer=pchar.
  • Remedy: Change the relevant virtual methods to use TRecordBuffer for buffer parameters. Define TRecordBuffer=pansichar to keep older Delphis and FPCs working. In places where a buffer is typecasted, don't use pchar but the symbol TRecordbuffer.

DLLParam changed from Longint into PtrInt

  • Old behaviour: DLLParam was of type Longint even on Win64.
  • New behaviour: DLLParam is now of type PtrInt so also on 64 Bit systems.
  • Reason: Prevent data loss, match the declaration in the Windows headers.
  • Remedy: Change the declaration of the procedures used as dll hook to take a PtrInt parameter instead of Longint.

TBookmark TBookmarkstr and TDataset.Bookmark change to Delphi2009+ compatible definitions

  • Old behaviour: TDataset.Bookmark was of type TBookmarkstr, TBookmarkstr=string, Tbookmark=pointer
  • New behaviour: TDataset.Bookmark is of type TBookmark, TBookmarkstr=ansistring, TBookmark=TBytes
  • Reason: D2009+ compatibility, where probably the fact that string became a 2-byte encoding was the trigger.
  • Remedy: Adjust typing in descendents and using code accordingly.

Some longtime deprecated functions in unit Unix have been removed.

  • Old behaviour: Unix.(f)statfs, Unix.shell and Unix.fsync symbols existed in unit Unix
  • New behaviour: Unix.(f)statfs, Unix.shell and Unix.fsync were removed
  • Reason: These were helper functions and leftovers from the 1.0.x->2.0.0 conversion, deprecated since 2007. Shell had non standarized conventions
  • Remedy: All but shell: use the same functions with a "fp" prefix. Shell: use fpsystem. If you checked the return value for other values than -1, a modification of the errorchecking might be necessary. Refer to your *nix documention, or have a look at the transformfpsystemtoshell function in tests/util/redir.pp in the FPC sources to see what a quick fix looks like.

Some symbols in unit Unix and Unixutils have been deprecated

  • Old behaviour: No deprecated warning for unixutils.getfs (several variants), unix.fpsystem(shortstring version only), Unix.MS_ constants and unix.tpipe
  • New behaviour: The compiler will emit a deprecated warning for these symbols. In future versions these may be removed.
  • Reason: getfs has been replaced by a wholly cross-platform function sysutils.getfilehandle long ago. fpsystem(shortstring) was a leftover of the 1.0.x->2.0.x migration (the ansistring version remains supported), the MS_ constants are for an msync call that is not supported by FPC, and thus have been unused and unchecked for over a decade and might date to kernel 1.x times, tpipe was the 1.0.x alias of baseunix.TFildes, the unit where the (fp)pipe was moved to in during 2.0 series.
  • Remedy: Use the new variants(sysutils.getfilehandle,fpsystem(ansistring),baseunix.tfildes). In the case of the MS_ constants, obtain current values for the constants from the same place where you got the code that uses them.

JSON parsing now uses UTF8 by default.

  • Old behaviour: The JSON parser/scanner converted unicode sequences to the system codepage.
  • New behaviour: The JSON parser and scanner now return UTF-8 strings by default.
  • Reason: The JSON standard specifies Unicode, which is now properly supported by the compiler.
  • Remedy: The old behaviour can be restored by setting the UseUTF8 property to False. The value of this property can be specified in the constructor of the scanner and/or parser.

TStrings.DelimitedText behavior changed (unit Classes)

  • Old behaviour: If StrictDelim is true, TStrings.DelimitedText did not completely follow the SDF format specification (which is defined in Delphi help) at least in case of spaces (and presumably other low ASCII characters) in front and at the end of fields as well as quotes and line endings. Worse, if StrictDelimiter is true, and in the cases mentioned above, saving a TString .DelimitedText and loading that text in another TString lead to differences between the two. Note: StrictDelimiter is false by default.
  • New behaviour: FPC follows Delphi behaviour.
  • Reason: Consistency (writing out and reading in DelimitedText should result in the same strings), Delphi compatibility (following the SDF specification).
  • Remedy: Review your existing code that reads or write DelimitedText; if necessary convert data or write converter code. See tests\webtbs\tw19610.pp for a detailed test.

fcl-image TTiffIDF renamed to TTiffIFD

  • Old behaviour: The tiff helper class for the "image file directory" was misspelled TiffIDF (tiffcmn unit)
  • New behaviour: Now renamed to TTiffIFD
  • Reason: Consistency, low usage
  • Remedy: Rename identifier as appropriate.

unit libc issues a deprecated warning

  • Old behaviour: While deprecated for years the libc unit didn't issue a deprecated warning
  • New behaviour: A deprecated warning is shown when unit libc is used, urging your to update.
  • Reason: unit libc is a Kylix legacy unit, with limited portability
  • Remedy: Use proper FPC units as described in libc unit

Language Changes

Anonymous inherited calls

  • Old behaviour: An anonymous inherited call could call through to any method in a parent class that accepted arguments compatible to the parameters of the current method.
  • New behaviour: An anonymous inherited call is guaranteed to always call through to the method in a parent class that was overridden by the current one.
  • Example: See http://svn.freepascal.org/svn/fpc/trunk/tests/tbs/tb0577.pp. In previous FPC versions, the inherited call in tc3.test would call through to tc2.test(b: byte; l: longint = 1234);. Now it calls through to tc.test.
  • Reason: Conform to the FPC documentation, Delphi-compatibility.
  • Remedy: If you wish the compiler to decide which method to call based on the specified parameters, use a fully specified inherited call expression such as inherited test(b).

Overload modifier must be present in the interface

  • Old behaviour: It was possible to declare a function/procedure/method as overload only in the implementation.
  • New behaviour: If an overload directive is used, it must also appear in the interface.
  • Reason: The old mechanism could cause hard to find problems (depending on whether or not the implementation was already parsed, the compiler would treat the routine as if it were declared with/without overload), it could cause unwanted unit recompilations due to interface crc changes, and Delphi compatibility.
  • Remedy: Make sure that the overload modifier is present both in the interface and in the implementation if you use it.

Variant overload preference for string types

  • Old behaviour: Preference for string types was (from better to worse): ShortString, AnsiString, WideString, UnicodeString
  • New behaviour: Preference for string types now (from better to worse): WideString, UnicodeString, AnsiString, ShortString
  • Reason: Unicode characters and codepage information will not lose during the conversion and unicode Delphi compatibility.
  • Remedy: Use explicit conversion (e.g. ShortString(V)) if it is needed to pass variant to routine with paticular string type argument.

Default values in implementation but not in interface/forward declaration

  • Old behaviour: The implementation of a routine could declare default values even if the interface declaration did not have any.
  • New behaviour: Default values, if any, must be specified in the interface. They can be repeated in the implementation, but that is not required (just like it was not in the past).
  • Reason: Default parameters specified only in the implementation are not, and cannot, be propagated to the interface since a unit's interface can be used before the implementation has been parsed (see http://bugs.freepascal.org/view.php?id=19434), Delphi compatibility.
  • Remedy: Always specify default parameter values (also) in the interface/forward declaration of a routine.

Default values are now properly typechecked

  • Old behaviour: The compiler did not detect default values for parameters of which the type did not in any way correspond to the parameter type.
  • New behaviour: The compiler now properly checks whether the type of the constant matches the parameter's type when parsing default values.
  • Reason: Proper type checking is one of the fundamental properties of the Pascal language; Delphi compatibility.
  • Remedy: Add a typecast around default values that now result in compiler errors, or correct the type of such parameters.

Recursive parameterless function calls in MacPas mode

  • Old behaviour: When using the name of a function inside its own body on the right hand side of an expression, the compiler treated this as a read of the last value assigned to the function result in MacPas mode.
  • New behaviour: The compiler will now treat such occurrences of the function name as recursive function calls in MacPas mode.
  • Reason: Compatibility with Mac Pascal compilers.
  • Remedy: If you wish to read the current function result value, compile the code with {$modeswitch result}, after which you can use the result alias for that value. Note that the use of this mode switch can also result in different behaviour compared to traditional Mac Pascal compilers.

"strict protected" visibility modifier

  • Old behaviour: strict protected did not correctly limit the visibility of symbols declared in different units.
  • New behaviour: strict protected symbols can now only be accessed from descendent classes, regardless of where they are defined.
  • Reason: Fix behaviour to conform to specification/documentation, Delphi compatibility.
  • Remedy: Use protected or public if less strict accessibility checks are desired.

Darwin/i386 and iPhoneSim/i386

Location of certain function result types

  • Old behaviour: Small records and method pointers were always returned according to the official ABI.
  • New behaviour: When a calling convention other than cdecl, cppdecl or mwpascal is used, the same convention as on other platforms is now used.
  • Reason: Better compatibility with assembler code written for other platforms.
  • Remedy: Update your assembler code, or better: if possible, convert it to Pascal.

All Darwin/Mac OS X/iOS

MacOSAll unit: changed parameter and opaque types

  • Change: The headers have been updated to the Mac OS X 10.8 SDK, and in this process a number of signatures have been changed/corrected, and several opaque types have been changed from ^SInt32 into pointers to different/incompatible empty records.
  • Reason: The reasons for the signature changes are detailed below. The opaque types have been made incompatible so that the compiler can give error messages when trying to use one opaque type instead of another (e.g., in the past the compiler did not complain when passing a ControlRef to a routine that expected a WindowPtr).
  • Remedy: Adjust your code to conform to the new signatures. Regarding the opaque types, that means that these types are no longer assignment-compatible. Some of the more prominent ones that may affect existing, correct, code are HIObject and ControlRef=HIViewRef. This may require adding typecasts to keep code compiling (the same typecasts are required in C)
  • Changes: (apart from the opaque type changes)
    • CGGLContextCreate : fixed first parameter (was "var", now is value parameter)
    • CFHostGetAddressing: var hasBeenResolved: boolean -> booleanptr because can be nil
    • CFHostGetNames: var hasBeenResolved: boolean -> booleanptr because can be nil
    • ColorSyncIterateInstalledProfiles: var seed: UInt32 -> UInt32Ptr because can be nil
    • AudioStreamGetPropertyInfo: outSize and outWritable changed to pointer because can be nil
    • cblas (several var-parametes changed to pointers because they represent arrays):
      • cblas_sswap, cblas_dswap: X, Y
      • cblas_scopy, cblas_dcopy: Y
      • cblas_saxpy, cblas_daxpy: Y
      • catlas_saxpby, catlas_daxpby: Y
      • catlas_sset, catlas_dset: X
      • cblas_sscal, cblas_dscal: X
      • cblas_sgemv, cblas_dgemv: X
      • cblas_strmv, cblas_dtrmv: X
      • cblas_stbmv, cblas_dtbmv: X
      • cblas_stpmv, cblas_dtpmv: Ap, X
      • cblas_strsv, cblas_dtrsv: X
      • cblas_stbsv, cblas_dtbsv: X
      • cblas_stpsv, cblas_dtpsv: Ap, X
      • cblas_ssymv, cblas_dsymv: X
      • cblas_ssbmv, cblas_dsbmv: Y
      • cblas_sspmv, cblas_dspmv: Ap, Y
      • cblas_sger, cblas_dger: A
      • cblas_ssyr, cblas_dsyr: A
      • cblas_sspr, cblas_dspr: Ap
      • cblas_ssyr2, cblas_dsyr2: A
      • cblas_sspr2, cblas_dspr2: A
      • cblas_sgemm, cblas_sgemm: C
      • cblas_ssymm, cblas_Dsymm: C
      • cblas_ssyrk, cblas_dsyrk: C
      • cblas_ssyr2k, cblas_dsyr2k: C
      • cblas_strmm, cblas_dtrmm: B
      • cblas_strsm, cblas_strsm: B
    • vBLAS (idem)
      • SDOT: X, Y
      • SNRM2: X
      • SASUM: X
      • ISAMAX: X
      • SSWAP: X, Y
      • SCOPY: X, Y
      • SAXPY: X, Y
      • SROT: X, Y
      • SSCAL: X
      • SGEMV, A, X, Y
      • SGEMM: A, B, C
    • vDSP (idem)
      • vDSP_sve_svesq, vDSP_sve_svesqD: __vDSP_A
      • vDSP_normalize, vDSP_normalizeD: __vDSP_A, __vDSP_C

Other

UPX support has been removed

  • Old behaviour: There was some leftover UPX (an executable packer) support in the FPC Makefiles, and DOS and Windows FPC releases included an UPX binary.
  • New behaviour: All removed.
  • Reason: Release binaries haven't been UPX'ed for a while. The size of the FPC executables is generally insignificant these days compared to the total installation size, and using UPX occasionally causes some minor annoyances (false positives from virus scanners, worse paging behaviour by the OS, incompatibilities with certain executable sections, ...)
  • Remedy: Download and install UPX yourself from its homepage.

See also