Sign in Join
Wiki copytemporary

User Changes 2.6.2: what changed

Revision 0 to 1. Removed lines have a minus sign; added lines have a plus sign.

Title: User Changes 2.6.2

OldNewLine
1+## About this page
2+
3+Below you can find a list of intentional changes since the [[User Changes 2.6.0|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 [[FPC New Features Trunk|here]].
4+
5+## All systems
6+
7+### Language changes
8+
9+#### Anonymous inherited calls
10+
11+- **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.
12+- **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.
13+- **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*.
14+- **Reason**: Conform to the FPC documentation, Delphi-compatibility.
15+- **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)*.
16+
17+#### *Overload* modifier must be present in the interface
18+
19+- **Old behaviour**: It was possible to declare a function/procedure/method as *overload* only in the implementation.
20+- **New behaviour**: If an *overload* directive is used, it must also appear in the interface.
21+- **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.
22+- **Remedy**: Make sure that the *overload* modifier is present both in the interface and in the implementation if you use it.
23+
24+### Unit changes
25+
26+#### Several methods of TDataset changes signature (TRecordBuffer)
27+
28+- **Old behaviour**: Several (virtual) methods of TDataset have parameters of type "pchar", which are often called "buffer".
29+- **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.
30+- **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.
31+- **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.
32+
33+#### DLLParam changed from Longint into PtrInt
34+
35+- **Old behaviour**: DLLParam was of type Longint even on Win64.
36+- **New behaviour**: DLLParam is now of type PtrInt so also on 64 Bit systems.
37+- **Reason**: Prevent data loss, match the declaration in the Windows headers.
38+- **Remedy**: Change the declaration of the procedures used as dll hook to take a PtrInt parameter instead of Longint.
39+
40+#### Some symbols in unit Unix and Unixutils have been deprecated
41+
42+- **Old behaviour**: No deprecated warning for unixutils.getfs (several variants), unix.fpsystem(shortstring version only), Unix.MS_ constants and unix.tpipe. unix.statfs
43+- **New behaviour**: The compiler will emit a deprecated warning for these symbols. In future versions these may be removed.
44+- **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. Unix.statfs is an overloaded version that wasn't properly renamed to fp* prefix when the others were renamed in 2.4.0
45+- **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.
46+
47+#### TStrings.DelimitedText behavior changed (unit Classes)
48+
49+- **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.
50+- **New behaviour**: FPC follows Delphi behaviour.
51+- **Reason**: Consistency (writing out and reading in DelimitedText should result in the same strings), Delphi compatibility (following the SDF specification).
52+- **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.
53+
54+#### fcl-image TTiffIDF renamed to TTiffIFD
55+
56+- **Old behaviour**: The tiff helper class for the "image file directory" was misspelled TiffIDF (tiffcmn unit)
57+- **New behaviour**: Now renamed to TTiffIFD
58+- **Reason**: Consistency, low usage
59+- **Remedy**: Rename identifier as appropriate.
60+
61+#### unit libc issues a deprecated warning
62+
63+- **Old behaviour**: While deprecated for years the [[libc unit]] didn't issue a deprecated warning
64+- **New behaviour**: A deprecated warning is shown when unit libc is used, urging your to update.
65+- **Reason**: unit libc is a Kylix legacy unit, with limited portability
66+- **Remedy**: Use proper FPC units as described in [[libc unit]]
67+
68+## Other
69+
70+### UPX support has been removed
71+
72+- **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.
73+- **New behaviour**: All removed.
74+- **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, ...)
75+- **Remedy**: Download and install UPX yourself from its [homepage](http://upx.sourceforge.net/) and in general reevaluate the need for it.
76+
77+## Previous release notes
78+
79+---
80+*From the Free Pascal wiki, page "User Changes 2.6.2", as it stood on 2015-05-09 after a change by Socke, out of the wiki's dump of 2024-05-26. Copyright stays with the author who wrote it, according to the old wiki's [[Licensing]] page. If you have concerns about this material, [message the admin](/wiki-contact).*
81+Category: FPC User Changes by release
82+Category: Release Notes

Back to history