User Changes Trunk

From Free Pascal wiki
Revision as of 20:11, 8 September 2007 by Jonas (talk | contribs) (+ section about new alignment/sizes of records)
Jump to navigationJump to search

About this page

Below you can find a list of intentional changes since the the previous 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));

Alignment of record variables

  • Old behaviour: Variables of record types (not just their fields, but the records as a whole when declared as independent variables) would be aligned at most to the maximum alignment of their fields, limited by the maximum field alignment set for the target. This same limit was used to determine padding of the record size.
  • New behaviour: Variables of record types are now always aligned inside stack frames or as global variables in a way which provides optimal alignment for their embedded fields, regardless of the used packrecords setting. Moreover, unpacked records are also padded up to a size which is a multiple of this alignment (to also provide optimal alignment inside arrays of such records). The alignment of record fields inside other records obviously only depends on the packing settings of the "parent" record.
  • Example: type tr = packed record d: double; b: byte; end; used to be aligned to 1 byte in stack frames and as global variable. Now it will be aligned to 8 bytes (limited by the maximum global/local alignment settings). Its size will remain 9 bytes as before (because of the packed specifier).
  • Reason: Performance.
  • Effect: The size of some non-packed records may change compared to previous versions. The different alignment rules cannot impact your code unless you are making unsupported assumptions (like taking the address of a local variable, adding some value to it, and expecting that you are now pointing at the next local variable).
  • Remedy: If you depend on the layout and/or size of a record staying the same, always declare it as packed. Non-packed records are free to be changed by the compiler in any way that it sees fit.