User Changes 3.2.0: what changed

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

Title: User Changes 3.2.0

New		Line
1	+	## About this page
2	+
3	+	Listed below are intentional changes made to the FPC compiler (3.2) since the [[User Changes 3.0.4\|previous release]] that may break existing code. The list includes reasons why these changes have been implemented, and suggestions for how you might adapt your code if you find that previously working code has been adversely affected by these recent changes.
4	+
5	+	The list of new features that do not break existing code can be found [[FPC New Features 3.2\|here]].
6	+
7	+	Please add revision numbers to the entries from now on. This facilitates moving merged items to the user changes of a release.
8	+
9	+	## All systems
10	+
11	+	### Usage Changes
12	+
13	+	#### Library search directories and custom sysroots
14	+
15	+	- Old behaviour: When specifying a custom sysroot (-XR), all library search directories (both built-in and specified via options) were relative to this sysroot
16	+	- New behaviour: Library search directories are only relative to the sysroot if they start with "=".
17	+	- Reason: Allow specifying custom search directories for libraries outside a sysroot.
18	+	- Remedy: Add "=" at the start of library search paths if you wish them to be relative to any specified sysroot.
19	+	- Example:
20	+	- -XR/Data/Developer/MacOSX10.4u.sdk/ -Fl=/opt/X11/lib: will search for libraries in /Data/Developer/MacOSX10.4u.sdk/opt/X11/lib
21	+	- -XR/Data/Developer/MacOSX10.4u.sdk/ -Fl/opt/X11/lib: will search for libraries in /opt/X11/lib
22	+	- -Fl=/opt/X11/lib: will search for libraries in /opt/X11/lib
23	+	- -Fl/opt/X11/lib: will search for libraries in /opt/X11/lib
24	+	- svn: 43279, 43302, 43306, 43312
25	+
26	+	#### Additional `{$include}` variables
27	+
28	+	Overview
29	+	The [[$include\|{$include}]] directive now recognizes the additional internal variables
30	+
31	+	- `{$include %currentRoutine%}`
32	+	- `{$include %dateYear%}`, `{$include %dateMonth%}`, `{$include %dateDay%}`
33	+	- `{$include %timeHour%}`, `{$include %timeMinute%}`, `{$include %timeSecond%}`
34	+
35	+	Remedy
36	+	You cannot name and use environment variable expansion with any of those names.
37	+
38	+	svn
39	+	30873 (current routine), 38329 (date and time)
40	+
41	+	### Implementation Changes
42	+
43	+	#### Dynamic array parameters are passed like pointers
44	+
45	+	- Old behaviour: When using the default calling convention, dynamic array parameters were passed on the stack.
46	+	- New behaviour: When using the default calling convention, dynamic array parameters are now passed like a pointer (which may be in a register).
47	+	- Reason: Delphi compatibility, ensuring that SetPointerProp can be used with dynamic arrays.
48	+	- Remedy: Adjust pure assembler routines that have dynamic array parameters.
49	+	- svn: 30870, 30878, 31622
50	+
51	+	#### VMT Interface table uses private variable FPC_EMPTYINTF
52	+
53	+	- Old behaviour: The vIntfTable field has three possible values:
54	+	- Nil if the class doesn't implement any interface (but an ancestor might)
55	+	- A pointer to an interface table (with count \<\> 0) if the class implements any interface
56	+	- A pointer to FPC_EMPTYINTF if neither the class itself nor any ancestor implements an interface
57	+	- New behaviour: The vIntfTable field has two possible values:
58	+	- Nil if neither the class nor any ancestor implements an interface
59	+	- A pointer to an interface table in any other case
60	+	- Reason: FPC_EMPTYINTF had to be removed due to dynamic packages support on PE-based systems
61	+	- Remedy: Adjust code accordingly
62	+	- svn: 34087
63	+
64	+	#### Modeswitch TypeHelpers in Delphi modes enables type helper-syntax
65	+
66	+	- Old behaviour: The modeswitch TypeHelpers is enabled by default in Delphi modes and allows to extend primitive types with record helper types.
67	+	- New behaviour:
68	+	- The modeswitch is no longer set by default.
69	+	- Primitive types can always be extended by record helpers in Delphi modes.
70	+	- The modeswitch enables the type helper-syntax as known from non-Delphi modes.
71	+	- Reason: The previous implementation of the modeswitch was illogical additionally there were user wishes to allow inheritance for record helpers in Delphi modes.
72	+	- Remedy: The only problems arise if one disabled the modeswitch on purpose which now no longer disallows the extension of primitive types.
73	+	- svn: 37225
74	+
75	+	#### Class references in a class VMT's field table
76	+
77	+	- Old behaviour: The class array of the vFieldTable of the VMT contains an array of TClass entries
78	+	- New behaviour: The class array of the vFieldTable of the VMT contains an array of PClass entries
79	+	- Reason: As for the RTTI the indirect references are necessary for dynamic packages.
80	+	- Remedy: Use an additional dereferentiation to access the class type.
81	+	- svn: 37485
82	+
83	+	#### Property field access lists no longer allows classes
84	+
85	+	- Old behaviour: A field access list for a property is allowed to contain implicit dereferences in the form of fields of class instances.
86	+	- New behaviour: A field access list for a property must only contain record or (TP style) object fields.
87	+	- Reason:
88	+	- Delphi compatibility
89	+	- This resulted in an internal error for published properties
90	+	- Remedy:
91	+	- Switch the fields to records or objects
92	+	- Use a method with inline modifier that will result in similar performance
93	+	- svn: 40656
94	+	- Example: The following code now fails:
95	+
96	+	``` pascal
97	+	unit Test;
98	+	{$mode objfpc}
99	+
100	+	interface
101	+
102	+	type
103	+	TTest1 = class
104	+	Field: String;
105	+	end;
106	+
107	+	TTest2 = class
108	+	private
109	+	fTest1: TTest1;
110	+	public
111	+	property Prop: String read fTest1.Field; // Error "Record or object type expected"
112	+	end;
113	+
114	+	implementation
115	+
116	+	end.
117	+	```
118	+
119	+	#### Range checking for enumeration constants in Delphi mode
120	+
121	+	- Old behaviour: Out-of-range enumeration constants never caused an error in Delphi mode, because very early versions of Delphi did not either.
122	+	- New behaviour: Out-of-range enumeration constants cause an error in Delphi mode, even if range checking is disabled. Current Delphi versions (and even older ones, such as Delphi 7) behave the same.
123	+	- Reason: Delphi-compatibility.
124	+	- Remedy: Fix the range errors.
125	+	- svn: 42272, 42275
126	+
127	+	### Language Changes
128	+
129	+	#### Visibility of generic type parameters
130	+
131	+	- Old behaviour: Type parameters of generics had public visibility.
132	+	- New behaviour: Type parameters of generics now have strict private visibility.
133	+	- Reason: With the previous visibility it was possible to create code that leads to infinite loops during compilation or other hard to debug errors. In addition there is no real possibility to work around this issue (for an example see [this](http://bugs.freepascal.org/view.php?id=25917) bug report). Also the fix is Delphi compatible.
134	+	- Remedy: Declare a type alias for the type parameter with the desired visibility.
135	+	- Example: In the following example T is declared as strict private, while TAlias is declared as public and thus can be used as before the change.
136	+
137	+	``` pascal
138	+	type
139	+	generic TTest<T> = class
140	+	public type
141	+	TAlias = T;
142	+	end;
143	+	```
144	+
145	+	#### Parsing of specialize has been changed
146	+
147	+	- Old behaviour: specialize was used to initialize a specialization and was followed by a type name that might contain a unit name and parent types.
148	+	- New behaviour: specialize is now considered part of the specialized type, just as generic is. This means that unit names and parent types need to be used before the part containing the specialize.
149	+	- Reason: This allows for a more logical usage of specialize in context with nested types (especially if multiple specializations are involved) and more importantly generic functions and methods.
150	+	- Remedy: Put the specialize directly in front of the type which needs to be specialized.
151	+
152	+	#### Operator overload + no longer allowed for dynamic arrays
153	+
154	+	- Old behaviour: The + operator could be overloaded for dynamic array types.
155	+	- New behaviour: The + operator for dynamic array types can no longer be overloaded if the modeswitch ArrayOperators is active (default in Delphi modes).
156	+	- Reason: When the modeswitch ArrayOperators is active a + operator is now provided by the compiler itself which concatenates two arrays together.
157	+	- Remedy:
158	+	- Disable the modeswitch (for Delphi modes this can be done with {\$modeswitch ArrayOperators-}).
159	+	- If your operator merely concatenates two arrays then remove the overload.
160	+	- If your operator does something different or more then use a different operator.
161	+	- Note: A warning is provided by the compiler if an overload is in scope, but not used due to the internal operator.
162	+
163	+	#### Generic type parameters need to match
164	+
165	+	- Old behaviour: When defining the method of a generic class or record it was possible to use different names for the type parameters than those that were used in the declaration.
166	+	- New behaviour: The order and name of generic type parameters of the class or record type in the method definition has to match the order and name of generic types parameters of the class or record declaration.
167	+	- Reason: To avoid the user making mistakes e.g. when the order of parameters is swapped. Also this is compatible to at least newer Delphi versions.
168	+	- Remedy: Use the correct generic type parameters for the definition.
169	+	- svn: 39701
170	+
171	+	#### Visibility of methods implementing interface methods
172	+
173	+	- Old behaviour: All methods in a class hierarchy were considered when looking for methods to implement interfaces
174	+	- New behaviour: Only methods visible in the class that is declared as implementing the method are considered.
175	+	- Reason: The symbol visibility rules should be respected in all cases. This fix is Delphi-compatible.
176	+	- Remedy: Make (strict) private methods that should implement interface methods in descendant classes protected or public.
177	+	- svn: 40645
178	+
179	+	#### Methods implementing interface methods and overloads
180	+
181	+	- Old behaviour: All methods in a class hierarchy were considered when looking for methods to implement interfaces.
182	+	- New behaviour: In case of overloads, searching stops when a method is found that has the right name but not the overload directive. Note that this directive is automatically inherited when overriding a method.
183	+	- Reason: The same happens when calling a method, and the symbol resolution rules should be the same in all cases. This fix is Delphi-compatible.
184	+	- Remedy: Add an overload directive to methods of which all overloads should be visible in the entire class hierarchy.
185	+	- Example:
186	+	- [Bug found by this change](https://gitlab.com/freepascal.org/fpc/source/-/tree/main/tests/webtbs/tw27349.pp) (previously, on non-Windows platforms the _Addref method of TInterfacedObject was selected for implementing by the classes implementing tmyintf).
187	+	- [Example that no longer compiles](https://gitlab.com/freepascal.org/fpc/source/-/tree/main/tests/tbf/tb0267.pp).
188	+	- [Fixed example](https://gitlab.com/freepascal.org/fpc/source/-/tree/main/tests/tbs/tb0654.pp).
189	+	- svn: 40683
190	+
191	+	#### Objective-C "Related Result Type"
192	+
193	+	- Old behaviour: The type checking system always evaluated calls to Objective-C methods as them returning the declared result type.
194	+	- New behaviour: The type checking system now takes into account the ["related result type"](http://releases.llvm.org/8.0.0/tools/clang/docs/LanguageExtensions.html#objective-c-features) rule from Objective-C. This means that certain methods are now assumed to always return an instance whose type is compatible with the object to which the message was sent (i.e., it's the same, or inherits from it). This is done for the following methods, provided their declared result type is also compatible with the class type in which the method is declared:
195	+	- instance methods whose first lower case word in the message name is init or new
196	+	- class methods whose first lower case word in the message name is autorelease, init, retain, or self
197	+	- Reason: Compatibility with translations of more recent versions of Cocoa headers
198	+	- Remedy: Normally this should not break existing, correct code. If it does, you can probably fix it by removing superfluous typecasts.
199	+	- Example:
200	+
201	+	``` pascal
202	+	{$mode objfpc}
203	+	{$modeswitch objectivec1}
204	+
205	+	type
206	+	FPCMyType = objcclass
207	+	function init: id; message 'init';
208	+	class function alloc: FPCMyType; message 'initWithValue';
209	+	// since ObjCBool is not related to FPCMyType, the "related result type" rule will not apply here
210	+	// even though the message starts with "retain" and it's a class method
211	+	class function retainCounting: ObjCBool; message 'retainCounting';
212	+	end;
213	+
214	+	...
215	+
216	+	var
217	+	a: NSArray;
218	+	begin
219	+	// will give an error even though FPCMyType returns 'id', because 'id' is related to
220	+	// FPCMyType and hence the compiler will now interpret the 'init' message as returning
221	+	// an "FPCMyType" when called. Do note that the actual return type of "init" remains
222	+	// "id" in all other contexts, e.g. when deciding override compatibility. The declaration
223	+	// of that method is not modified, and the only changed behviour is that when calling it
224	+	// the result type is statically assumed to be of FPCMyType.
225	+	a:=FPCMyType.alloc.init;
226	+	end;
227	+	```
228	+
229	+	- svn: r42816
230	+
231	+	### RTTI changes
232	+
233	+	#### RTTI for Interfaces (published property count)
234	+
235	+	- Old behavior: The property RTTI data of an interface (both COM and Corba) immediately followed the TTypeData record without any count.
236	+	- New behavior: Before the property RTTI data is now a Word count field that specifies the amount of properties
237	+	- Reason: Both user request and usability.
238	+	- Remedy: Adjust pointer offsets accessing the property data accordingly.
239	+
240	+	#### RTTI for COM Interfaces (IID String)
241	+
242	+	- Old behavior: COM interfaces contain an undocumented IIDStr between the unit name IntfUnit and the property data.
243	+	- New behavior: The undocumented field has been removed.
244	+	- Reason: The IID of COM interfaces can always be represented as GUID, thus the undocumented IIDStr field is redundant.
245	+	- Remedy: Use the GUID field and convert that to a String.
246	+
247	+	#### RTTI Binary format change
248	+
249	+	- Old behavior: References to other types are designated by PTypeInfo.
250	+	- New behavior: References to other types are designated by PPTypeInfo.
251	+	- Reason: While the change in the binary format is Delphi-compatible the reason for this is the introduction of the support for dynamic packages and the rules of the PE file format (Windows) that need to be played by.
252	+	- Remedy: If you don't access the binary data directly then there should be no change necessary. Otherwise you need to add in a further derefentiation.
253	+	- Note:
254	+	- The PPTypeInfo value itself will be Nil if there's no reference, not the PTypeInfo reference stored in it.
255	+	- This does not apply to TObject.ClassInfo which still returns a PTypeInfo
256	+
257	+	#### RTTI for Corba Interfaces (IID String)
258	+
259	+	- Old behavior: IIDStr is a field of TTypeData.
260	+	- New behavior: IIDStr is a property of TTypeData.
261	+	- Reason: The compiler assumes the RawIntfUnit field immediately preceding IIDStr is a ShortString of length 255 despite the corresponding binary data only having the length of the string it contains, thus accessing incorrect data.
262	+	- Remedy: If you merely accessed the data nothing changes, but the data following IIDStr needs to be accessed differently as RawIntfUnit is the last visible field.
263	+	- svn: 35026
264	+
265	+	#### Reference to Record Init Information
266	+
267	+	- Old behavior: Field RecSize follows directly after start of TTypeData record.
268	+	- New behavior: Field RecSize is preceeded by pointer field RecInitInfo which points to a TTypeInfo for the record init information (the TTypeInfo for that is followed by TRecInitData).
269	+	- Reason: With the record init information one can more quickly decide whehther a record needs to be classed as managed or not which is among others useful for the IsManaged() function of the Rtti unit.
270	+	- Remedy: If you relied on the relative position of RecSize in TTypeData you'll need to adjust your code.
271	+	- Note: The TRecInitData shares its first three fields with a record's TTypeData with the difference that the pointer to the init information is Nil.
272	+	- svn: 35125, 35134
273	+
274	+	#### TOrdType extended
275	+
276	+	- Old behavior: TOrdType contains entries for 8-, 16- and 32-bit widths.
277	+	- New behavior: TOrdType contains entries for 8-, 16-, 32- and 64-bit widths.
278	+	- Reason: Without extending TOrdType it wouldn't be possible to correctly represent Boolean type of 64-bit width as they couldn't be differentiated from ordinary Integers with a minimum of 0 and maximum of 1 for the Pascal Boolean type and minium of -1 and maximum of 0 for the Windows Boolean type.
279	+	- Remedy: Adjust arrays that have TOrdType as index.
280	+	- svn: 35135
281	+
282	+	#### New OrdType field for tkInt64 and tkQWord
283	+
284	+	- Old behavior: MinInt64Value and MinQWordValue follow directly after start of TTypeData record.
285	+	- New behavior: MinInt64Value and MinQWordValue are preceeded by a OrdType field which explicitely designates them as otSQWord or otUQword respectively.
286	+	- Reason: To allow for 64-bit Booleans to be represented correctly the tkInt64 and tkQWord branches of TTypeData had to become part of the tkInteger (aka Ordinal) branch and thus they gained the OrdType field.
287	+	- Remedy: If your code relied on the relative position of MinInt64Value and MinQWordValue towards the start of the TTypeData record it needs to be adjusted.
288	+	- svn: 35135
289	+
290	+	#### First field of TProcedureParam changed
291	+
292	+	- Old behavior: First field of TProcedureParam is called Flags and has type Byte.
293	+	- New behavior: First field of TProcedureParam is called ParamFlags and has type TParamFlags and there is a property called Flags of type Byte.
294	+	- Reason: Since TParamFlags is a set it might grow beyond the size of a Byte if more values are added to TParamFlag.
295	+	- Remedy: Most code should be able to use the backwards and Delphi compatible Flags property (at least if it only wants to check TParamFlag values of which the ordinal value is less than 8) other code should switch to using ParamFlags.
296	+	- svn: 35174
297	+
298	+	#### TParamFlag extended for constref
299	+
300	+	- Old behavior: TParamFlag has no entry for constref parameters.
301	+	- New behavior: TParamFlag has entry pfConstRef for constref parameters.
302	+	- Reason: To correctly detect constref parameters they need to be marked accordingly.
303	+	- Remedy: Adjust code that relies on the amount of elements contained in TParamFlag (e.g. case-statements or array indices).
304	+	- svn: 35175
305	+
306	+	#### Ranges of Boolean types adjusted
307	+
308	+	- Old behavior: ByteBool, WordBool and LongBool have a range of 0..-1.
309	+	- New behavior: ByteBool, WordBool and LongBool have a range of Low(LongInt) to High(LongInt).
310	+	- Reason: The old behavior simply cut the Low(Int64) and High(Int64) values used as ranges for the Boolean types which was wrong. That the ranges are not size dependant is Delphi compatible.
311	+	- Remedy: Adjust code that might have relied on the range being invalid.
312	+	- svn: 35184
313	+
314	+	#### OrdType of Boolean64 and QWordBool adjusted
315	+
316	+	- Old behavior: Boolean64 has OrdType otUByte and QWordBool has OrdType otSByte and their ranges are in MinValue and MaxValue.
317	+	- New behavior: Boolean64 has OrdType otUQWord with the range being in MinQWordValue and MaxQWordValue and QWordBool has OrdType otSQWord with the range being in MinInt64Value and MaxInt64Value.
318	+	- Reason: Both types have a size of 64-bit thus using a smaller size is incorrect.
319	+	- Remedy: Use the correct fields to retrieve the range boundaries of the types.
320	+	- svn: 35185
321	+
322	+	#### All Boolean types have TypeKind tkBool
323	+
324	+	- Old behavior: Boolean has TypeKind tkBool while the other Boolean types (Boolean16, Boolean32, Boolean64, ByteBool, WordBool, LongBool, QWordBool) have TypeKind tkInteger.
325	+	- New behavior: Boolean, Boolean16, Boolean32, Boolean64, ByteBool, WordBool, LongBool and QWordBool have TypeKind tkBool.
326	+	- Reason: Consistency and possibility to differentiate ordinary subranges from the real Boolean types.
327	+	- Remedy: Check for TypeKind tkBool instead of some "magic" to detect Boolean types.
328	+	- Note: Since fields can only appear once in a record the tkBool branch of TTypeData was not adjusted. This has no practical consequences however as all fields of a variant record are always accessible.
329	+	- svn: 35186, 35187
330	+
331	+	#### TParamFlag extended for hidden parameters
332	+
333	+	- Old behavior: TParamFlag has no entries for the hidden parameters (Array High, Self, Vmt, Result) of a function; SizeOf(TParamFlags) = 1
334	+	- New behavior: TParamFlag has entry pfHidden for hidden parameters in general and pfHigh for the high parameter of open array, pfSelf for the instance or class type, pfVmt for constructor's VMT parameter and pfResult if the result is passed as a parameter; SizeOf(TParamFlags) = 2
335	+	- Reason: As the plan is to use a manager based approach for Invoke() the RTL glue code should need as less knowledge as possible about calling conventions; due to this the locations of the hidden parameters needs to be known.
336	+	- Remedy: Adjust code that relies on the amount of elements contained in TParamFlag (e.g. case-statements or array indices) and also code that relies on the size of TParamFlags being 1 (SizeOf(TParamFlags) should be used instead).
337	+	- svn: 35267, 35286, 35291
338	+
339	+	#### Parameters of method pointer variables contain hidden parameters
340	+
341	+	- Old behavior: The parameters of method pointer variables only listed visible parameters.
342	+	- New behavior: The parameters of method pointer variables list all parameters.
343	+	- Reason: Makes the implementation of function call managers more stable in case the ABI should change.
344	+	- Remedy: Depending on your code either handle the new parameters or check for pfHidden in the parameter flags and ignore them.
345	+	- svn: 39885
346	+
347	+	#### Parameters of procedure variables contain hidden parameters
348	+
349	+	- Old behavior: The parameters of procedure variables only listed visible parameters.
350	+	- New behavior: The parameters of procedure variables list all parameters.
351	+	- Reason: Makes the implementation of function call managers more stable in case the ABI should change.
352	+	- Remedy: Depending on your code either handle the new parameters or check for pfHidden in the parameter flags and ignore them.
353	+	- svn: 39885
354	+
355	+	#### Implicit default values for real, pointer and string properties
356	+
357	+	- Old behavior: Real, pointer and string properties had no implicit values. Zero values and empty strings were stored by default.
358	+	- New behavior: Real, pointer and string properties have got implicit default values of 0 or \`\` respectively. As a result these values are not stored by default anymore.
359	+	- Reason: 1. Delphi compatibilty. 2. The default modifier cannot be used for these properties - there was no possibility to set 0 or \`\` default values in FPC 3.0.x.
360	+	- Remedy: The nodefault modifier must be added to the property declaration.
361	+	- More details: Check the [documentation](https://www.freepascal.org/docs-html/ref/refsu38.html) for more information. There were more fixes regarding string storage handling as well.
362	+	- svn: 37954
363	+
364	+	### Unit changes
365	+
366	+	#### SysUtils
367	+
368	+	##### faSymlink
369	+
370	+	- Old behaviour: faSymlink had the numerical value \$40. This was wrong on windows, and not compatible with Delphi.
371	+	- New behaviour: faSymlink has the numerical value \$400. Correct on windows.
372	+	- Reason for change: Wrong functionality and Delphi compatibility.
373	+	- Remedy: If you are using the old numerical constant \$40, simply use faSymlink instead.
374	+	- svn: r33340
375	+
376	+	##### FileExists on Unix-based systems
377	+
378	+	- Old behaviour: FileExists returns True for existing directories.
379	+	- New behaviour: FileExists does not return True for existing directories.
380	+	- Reason for change: Directories are not files, thus it was illogical for FileExists to return True for existing directories. Also this brings it in line with Windows and Delphi.
381	+	- Remedy: Use DirectoryExists to check for the existance of a directory
382	+	- svn: r43111
383	+
384	+	#### Classes.TList auto-growth
385	+
386	+	- Old behaviour: Lists with number of elements greater than 127 was expanded by 1/4 of its current capacity
387	+	- New behaviour: Adds two new thresholds. If number of elements is greater than 128 MB then list is expanded by constant amount of 16 MB elements (corresponds to 1/8 of 128 MB). If number of elements is greater then 8 MB then list is expanded by 1/8 of its current capacity.
388	+	- Reason for change: Avoid out-of-memory when very large lists are expanded
389	+	- svn: 34462
390	+
391	+	#### Math Min/Max
392	+
393	+	- Old behaviour: Mixing of QWord and Int64 was possible as there was no QWord overload. However the result might have been wrong.
394	+	- New behaviour: Overload for QWord exists now but mixed calls with Int64/QWord cause a compiler error.
395	+	- Reason for change: Delphi compatibility.
396	+	- Remedy: Apply an explicit typecast to one of the parameters so both are of the same type.
397	+	- svn: 39995
398	+
399	+	#### StrUtils AnsiStartsText/AnsiEndsText
400	+
401	+	- Old behaviour: AnsiStartsText or AnsiEndsText would return false for empty substring. This is not in line with Delphi, which returns true.
402	+	- New behaviour: AnsiStartsText or AnsiEndsText now return True for empty substring.
403	+	- Reason for change: Delphi compatibility.
404	+	- Remedy: Check explicitly for empty string if you counted on the old behaviour.
405	+	- svn: 38768
406	+
407	+	#### Types IStream interface and Classes TStreamAdapter
408	+
409	+	- Old behaviour: IStream Interface (classes unit and jwa units) used Int64 for various out parameters.
410	+	- New behaviour: IStream Interface (classes unit and jwa units) use QWord for various out parameters.
411	+	- Reason for change: The MS Headers use largeUint, which translates to QWord. The headers were for an old version of Delphi, which didn't know QWord.
412	+	- Remedy: If a class implementing this interface no longer compiles, adapt the signature of the interface's methods so they conform to the new definition.
413	+	- svn: 32820 and 35542
414	+
415	+	#### Baseunix (Linux only)
416	+
417	+	- Old behaviour: stat was an union, with one side the proper posix fieldnames, and the other deprecated, simplified 1.0.x fieldnames. The 1.0.x were already marked as deprecated for 2 major cycles.
418	+	- New behaviour: Deprecated 1.0.x fieldnames removed.
419	+	- Reason for change: Left over 1.0.x transition feature. Incompatible with other *nix ports.
420	+	- Remedy: Update fieldnames
421	+	- svn: 39644 and 39655
422	+
423	+	#### Classes TStrings.LoadFromStream/File encoding handling
424	+
425	+	- Old behaviour: The LoadFromStream call totally ignored the encoding of a file, loading it from a stream without regard for encoding, unless an encoding was specified.
426	+	- New behaviour: There is an overloaded call with a Boolean parameter 'IgnoreEncoding' which determines whether the encoding should be taken into account or not. By default, this parameter is False, meaning that LoadFromStream with just a stream as argument now calls the encoding-aware version of LoadFromStream, passing it an encoding of Nil, which mean the default encoding will be used.
427	+	- Reason for change: Delphi compatibility, and the corresponding changes in TStringStream constructors.
428	+	- Remedy: The old behaviour can be restored by setting the IgnoreEncoding parameter to 'True'.
429	+	- svn: 37962 and 37965
430	+
431	+	##### TStringStream now observes system encoding
432	+
433	+	- Old behaviour: TStringStream copied bytes as-is from the string specified in the constructor.
434	+	- New behaviour: Now bytes are fetched from the string using the encoding of the string.
435	+	- Reason: Delphi-compatibility
436	+	- Remedy: Pass a string with the correct encoding to TStringStream
437	+	- svn: 36758
438	+
439	+	##### TStringStream derives from TBytesStream
440	+
441	+	- Old behaviour: TStringStream is derived from TStream.
442	+	- New behaviour: TStringStream is derived from TBytesStream which in turn derives from TMemoryStream.
443	+	- Reason:
444	+	- needed for the above mentioned observing of the system encoding
445	+	- Delphi-compatibility
446	+	- Remedy: You need to adjust checks for inheritance.
447	+	- svn: 36758
448	+
449	+	#### DB
450	+
451	+	##### TParam.LoadFromFile sets share mode to fmShareDenyWrite
452	+
453	+	- Old behaviour: TFileStream.Create(FileName, fmOpenRead) was used, which has blocked subsequent access (also read-only) to same file
454	+	- New behaviour: TFileStream.Create(FileName, fmOpenRead+fmShareDenyWrite) is used, which does not block read access to same file
455	+	- Remedy: If your application requires exclusive access to file specify fmShareExclusive
456	+
457	+	##### CodePage aware TStringField and TMemoField
458	+
459	+	- Old behaviour: These character fields were agnostic to data they presented. IOW when we read content of such field using AsString data was passed from internal character buffer to string as is without any conversion.
460	+	- New behaviour: When those fields are created there can be specified CodePage (if none specified CP_ACP is assumed), which defines encoding of character data presented by this field. In case of sqlDB TSQLConnection.CharSet is usualy used. When we read content of such field using AsString character data are translated from fields code page to CP_ACP. Same translation happens when we read content using AsUTF8String (translation to CP_UTF8) or AsUnicodeString (translation to UTF-16). This change reflects CodePage aware strings introduced in FPC 3.
461	+
462	+	##### ODBC headers on Unix platforms defaults to 3.52 version
463	+
464	+	- Old behaviour: default was ODBCVER \$0351. SQLLEN/SQLULEN was 32 bit on 64 bit Unix platforms.
465	+	- New behaviour: default is ODBCVER \$0352. SQLLEN/SQLULEN is 64 bit on 64 bit Unix platforms. So it affects some ODBC API functions, which use parameters of this type (it affects also TODBCConnection of course). Also installed unixODBC/iODBC package must match this (in case of unixODBC you can check it using: "odbcinst -j" SQLLEN/SQLULEN must be 8 bytes on 64 bit platform).
466	+
467	+	##### TBlobData opaque type reworked to TBytes
468	+
469	+	- Old behaviour: TBlobData was declared as Ansistring
470	+	- New behaviour: TBlobData is declared as TBytes
471	+	- Reason for change: Delphi compatibility. Also helps to avoid possible code page recodings.
472	+	- Remedy: If your application used TBlobData as a string, you can use AsString for parameters, or convert to TBytes.
473	+
474	+	#### FGL
475	+
476	+	##### Declaration of type TTypeList changed
477	+
478	+	- Old behavior: The type TTypeList of the generic classes TFPGList\<\>, TFPGObjectList\<\> and TFPGInterfacedObjectList\<\> is declared as array\[0..GMaxListSize\] of T.
479	+	- New behavior: The type TTypeList of the generic classes TFPGList\<\>, TFPGObjectList\<\> and TFPGInterfacedObjectList\<\> is declared as PT.
480	+	- Reason: The way GMaxListSize was declared this could lead to too large static array types so that compilation aborted with a Data segment too large error. This also might have lead to incorrect range errors if range checking was turned on. As FPC supports indexed access to pointer types potential type problems when using the List property should be minimal.
481	+	- Remedy: If your application relies on PTypeList to be a static array type (instead of merely being indexable like an array) then you'll need to adjust your code.
482	+	- svn: 39464
483	+
484	+	#### objcbase
485	+
486	+	- Old behaviour: The Objective-C BOOL type was represented by objcbase.BOOL, which was the same as a Pascal boolean on all platforms.
487	+	- New behaviour: The Objective-C BOOL type is now represented by objcbase.ObjCBOOL, which maps to a boolean type that always corresponds to the one used in Objective-C (it differs on some platforms)
488	+	- Reason: The renaming was to prevent name clashes, and the type definition change was to fix interfacing issues between Objective-Pascal and Objective-C
489	+	- Remedy: change all uses of Boolean and BOOL in Objective-Pascal method definitions to ObjCBool.
490	+	- svn: 42483
491	+
492	+	#### SimpleIPC
493	+
494	+	- Old behaviour: ReadMessage is a procedure.
495	+	- New behaviour: ReadMessage is a function, returning a boolean, telling you whether a message was actually read.
496	+	- Reason: Provide more information to the user.
497	+	- Remedy: Handle the result if necessary. (if you used OnMessage, no change is necessary)
498	+	- svn: 36916
499	+
500	+	#### Process Unit
501	+
502	+	##### RunCommand
503	+
504	+	- Old behaviour: RunCommand had a few short sleeps to reduce CPU usage when the called process ran long.
505	+	- New behaviour: RunCommand defaults to no sleep unless poRunIdle is passed to the default parameter with process options.
506	+	- Reason for change: Applications that ran binaries to quickly obtain information were stalled by the pauses for no good reason. Servicing both short and long running binaries adequately without additional info seemed impossible due to slightly differing OS behaviours in pipe reading.
507	+	- Remedy: For short living processes that start up quickly: do nothing. For long running processes, pass poRunIdle as process option.
508	+	- svn: this changes was merged post RC1
509	+
510	+	##### poNoConsole on Windows
511	+
512	+	- Old behaviour: On Windows, poNoConsole mapped to Win API DETACH_PROCESS which still created standard input/output/error handles.
513	+	- New behaviour: poNoConsole maps to CREATE_NO_WINDOW, which doesn't create input/output/error handles. A new option poDetached allows for DETACH_PROCESS.
514	+	- Reason for change: poNoConsole still created a window in cases. (mantis [bug 32055](https://bugs.freepascal.org/view.php?id=32055)).
515	+	- Remedy: If you try to hide the console but still need stdin/stdout handles, then poNoConsole no longer works. You could try poDetached. See also [podetached forum thread](https://forum.lazarus.freepascal.org/index.php/topic,49631.msg360286.html#msg360286)
516	+	- svn: the poDetached option was created post RC1
517	+
518	+	#### fpHTTPClient and fpHTTPServer Units
519	+
520	+	- Old behaviour: Old units had SSL support hardcoded built in using OpenSSL.
521	+	- New behaviour: A program returns the error "No SSL Socket support compiled in" when doing a HTTPS request.
522	+	- Reason for change: pluggable architecture for SSL support.
523	+	- Remedy: Add one of the units opensslsockets (OpenSSL) or gnutlssockets (GNU TLS) to the uses clause of your program.
524	+
525	+	## Linux/Android platforms
526	+
527	+	### GNU Binutils 2.19.1 or later are required by default
528	+
529	+	- Old behaviour: The compiler invocation of the linker always resulted in a warning stating "did you forget -T?"
530	+	- New behaviour: The compiler now uses a different way to invoke the linker, which prevents this warning, but this requires functionality that is only available in GNU Binutils 2.19 and later.
531	+	- Reason: Get rid of the linker warning, which was caused by the fact that we used the linker in an unsupported way (and which hence occasionally caused issues).
532	+	- Remedy: If you have a system with an older version of GNU Binutils, you can use the new -X9 command line parameter to make the compiler revert to the old behaviour. You will not be able to (easily) bootstrap the new version of FPC on such a system though, so use another system with a more up-to-date version of GNU Binutils for that.
533	+
534	+	### Stack alignment on Linux/i386
535	+
536	+	- Old behaviour: The stack alignment for Linux/i386 was 4 bytes.
537	+	- New behaviour: The stack alignment for Linux/i386 is 16 bytes.
538	+	- Reason: Compatibility with the current Linux/i386 ABI and code generated by other Linux/i386 compilers.
539	+	- Remedy: This change will generally only impact inline assembly code that calls subroutines. If you have such code, ensure the stack is aligned to a multiple of 16 bytes before calling any subroutine. You may also have to realign the stack to 16 bytes after routines return in case they use a calling convention whereby the callee removes any stack arguments.
540	+
541	+	## i386 platforms
542	+
543	+	### The Pascal calling convention now follows Delphi conventions on 32 bit x86 platforms
544	+
545	+	- Old behaviour: The compiler always saved/restored all registers for a routine with the Pascal calling convention, even for pure assembler routines.
546	+	- New behaviour: The compiler now only has the old behaviour on the new i8086 (16 bit x86) target. On other targets, it only saves/restores the ebp/rbp register.
547	+	- Reason: On 16 bit x86 we follow Turbo Pascal behaviour (which also saved all of those registers), on other x86 platforms we follow Delphi behaviour.
548	+	- Remedy: Save/restore additional registers that are non-volatile according to the platform's ABI in case of pure assembler routines that use the Pascal calling convention (generally everything but EAX, ECX and EDX).
549	+	- Remarks
550	+	- On 64 bit x86-64 platforms, the Pascal calling convention is not supported and maps to the default calling convention defined by the ABI.
551	+
552	+	### -Ooasmcse/{\$optimization asmcse} has been removed
553	+
554	+	- Old behaviour: The compiler contained an assembler common subexpression elimination pass for the i386 platform.
555	+	- New behaviour: This optimisation pass has been removed from the compiler.
556	+	- Reason: That pass has been disabled by default since several releases because it hadn't been maintained, and it generated buggy code when combined with newer optimisation passes.
557	+	- Remedy: Don't use -Ooasmcse/{\$optimization asmcse} anymore.
558	+
559	+	## i8086 platforms
560	+
561	+	### the codepointer type has been changed in the small and compact memory models
562	+
563	+	- Old behaviour: The compiler used the NearPointer type for getting the address of procedures, functions and labels in the small and compact memory models.
564	+	- New behaviour: The compiler now uses the NearCsPointer type for getting the address of procedures, functions and labels in the small and compact memory models.
565	+	- Reason: Using NearCsPointer more accurately represents the fact that code lives in a separate segment in the small memory model and also allows reading the machine code of a procedure, which might be useful in low level code.
566	+	- Remedy: If your program uses the small memory model and needs any kind of fixing, you're very likely to get compile time type checking errors, since the Pointer and CodePointer types are no longer compatible. To fix these, change all your pointers that point to code to CodePointer instead of Pointer. Alternatively, if your program is really small (code+data\<=64k), you can switch to the tiny memory model, where the Pointer and CodePointer types are still compatible. If your program uses the compact memory model, it is unlikely to get any sort of breakage, since the Pointer and CodePointer types were already incompatible in this memory model.
567	+	- svn: 38691
568	+
569	+	## Darwin/macOS platforms
570	+
571	+	### Default Target macOS version
572	+
573	+	- Old behaviour: The default target version for the i386 (Intel 32 bits) platform was Mac OS X 10.4 (Tiger), and for the x86-64 (Intel 64 bits) was Mac OS X 10.5 (Leopard).
574	+	- New behaviour: The default target version for both the i386 (Intel 32 bits) and x86-64 (Intel 64 bits) platforms is now OS X 10.8 (Mountain Lion).
575	+	- Reason: On macOS 10.14, installing the command line tools no longer places the crt*.o files required when targeting the older targets in the same location as before, resulting in the need for custom command line options and modifications to fpc.cfg.
576	+	- Remedy: If you wish to target those earlier operating system versions, use the -WM10.4 resp. -WM10.5 command line parameters of the compiler, and if necessary point it to an SDK that still contains support for those operating system versions with the -XR/path/to/SDK parameter (and, if necessary, to an assembler/linker that supports removed architectures with -FD/path/to/clang_and_ld).
577	+	- svn: 43374
578	+
579	+	### Darwin/i386 and calling conventions whereby the callee removes stack parameters
580	+
581	+	- Old behaviour: The Darwin/i386 code generator treated all calling conventions as "caller removes stack parameters", even for calling conventions where this is normally not the case.
582	+	- New behaviour: The Darwin/i386 code generator correctly handles calling conventions whereby the callee removes the stack parameters. In particular, this changes the behaviour for the register, stdcall, safecall, and pascal calling conventions.
583	+	- Reason: Respect calling conventions, compatibility with other platforms and compilers.
584	+	- Remedy: If you have inline assembly code that dealt with this special behaviour of Darwin/i386 under older FPC versions, you can disable it for FPC 3.2 and later. Darwin/i386 now behaves according to the same (new) rules as [[User Changes 3.2\|Linux/i386]].
585	+	- svn: r43650
586	+
587	+	## Windows platforms
588	+
589	+	### GNU Binutils 2.25 or later are required by default
590	+
591	+	- Old behaviour: If the binary of a unit contains too many sections ( \> \$7fff) it fails to compile, due to the binary format not supporting that many sections.
592	+	- New behaviour: If the binary of a unit contains many sections ( \> \$7fff) it will be compiled using the BigObj format of COFF.
593	+	- Reason: Some units (e.g. packages\odata\src\sharepoint.pp) got so large that they could no longer be compiled using the normal COFF format. The internal assembler and linker can handle this format as can the GNU binutils, but only starting from 2.25 on.
594	+	- Remedy: If you compile with the binutils instead of using the internal assembler/linker then either use an up to date version of the binutils (\>= 2.25) or if you really need to use an older version, then pass -a5 which will disable the use of BigObj COFF files, though you'll then not be able to build the whole FPC distribution nor will you be able to link to such big units.
595	+
596	+	## Previous release notes
597	+
598	+	---
599	+	From the Free Pascal wiki, page "User Changes 3.2.0", as it stood on 2022-04-03 after a change by Alextpp, 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).
600	+	Category: FPC User Changes by release
601	+	Category: Release Notes
602	+	Category: Troubleshooting

Back to history