用户更改3.2.0
关于此页面
所有系统
用法更改
库搜索目录和自定义系统根
陈旧的行为 ：指定自定义sysroot（-XR）时，所有库搜索目录（内置目录和通过选项指定的目录）都与此系统根目录相关 新行为 ：如果库搜索目录以“=”开头，则它们仅相对于sysroot。 原因 ：允许为sysroot外部的库指定自定义搜索目录。 补救措施 ：如果希望它们相对于任何指定的sysroot，请在库搜索路径的开头添加“=”。 例子 : -XR/Data/Developer/MacOSX10.4Usdk/-Fl=/opt/X11/lib ：将在中搜索库 /数据/开发人员/MacOSX10.4usdk/opt/X11/lib -XR/Data/Developer/MacOSX10.4Usdk/-Fl/opt/X11/lib ：将在中搜索库 /opt/X11/lib -Fl=/opt/X11/lib ：将在中搜索库 /选择/X11/lib -Fl/opt/X11/lib ：将在中搜索库 /opt/X11/lib
svn公司 : 43279, 43302, 43306, 43312
附加 {$包含} 变量
概述 这个 {$包含} 指令现在识别附加的内部变量 {$include%currentRoutine%} {$include%dateYear%} , ｛$include%dateMonth%｝ , {$include%dateDay%} {$include%timeHour%} , {$include%timeMinute%} , {$include%timeSecond%}
补救措施 您不能将环境变量扩展与任何这些名称一起命名和使用。 svn公司 30873（当前例程），38329（日期和时间）
实施变更
动态数组参数像指针一样传递
陈旧的行为 ：使用默认调用约定时，在堆栈上传递动态数组参数。 新行为 ：使用默认调用约定时，动态数组参数现在像指针一样传递（可能位于寄存器中）。 原因 ：Delphi兼容性，确保SetPointerProp可以与动态数组一起使用。 补救措施 ：调整具有动态数组参数的纯汇编程序例程。 svn公司 : 30870, 30878, 31622
VMT接口表使用私有变量FPC_EMPTYINTF
陈旧的行为 ：vIntfTable字段有三个可能的值： 如果类没有实现任何接口，则为零（但祖先可能会实现） 如果类实现任何接口，则指向接口表（计数<>0）的指针 如果类本身或任何祖先都没有实现接口，则指向FPC_EMPTYINTF的指针
新行为 ：vIntfTable字段有两个可能的值： 如果类或任何祖先都没有实现接口，则为零 在任何其他情况下指向接口表的指针
原因 ：由于基于PE的系统上支持动态包，必须删除FPC_EMPTYINTF 补救措施 ：相应地调整代码 svn公司 : 34087
模式开关 类型助手 在Delphi模式中启用 类型帮助器 -语法
陈旧的行为 ：模式开关 类型助手 默认情况下在Delphi模式下启用，并允许使用 记录助手 类型。 新行为 : 默认情况下不再设置模式开关。 在Delphi模式下，记录助手始终可以扩展基本类型。 模式开关启用 类型帮助器 -非Delphi模式中已知的语法。
原因 ：之前的模式切换实现不合逻辑，此外，用户希望允许在Delphi模式下继承记录帮助程序。 补救措施 ：只有在故意禁用模式开关的情况下才会出现问题，现在不再禁止扩展基元类型。 svn公司 : 37225
类VMT字段表中的类引用
陈旧的行为 ：VMT的vFieldTable的类数组包含一个TClass条目数组 新行为 ：VMT的vFieldTable的类数组包含PClass条目数组 原因 ：对于RTTI，动态包需要间接引用。 补救措施 ：使用附加的取消引用来访问类类型。 svn公司 : 37485
属性字段访问列表不再允许类
陈旧的行为 ：允许属性的字段访问列表以类实例字段的形式包含隐式取消引用。 新行为 ：属性的字段访问列表只能包含记录或（TP样式）对象字段。 原因 : Delphi兼容性 这导致已发布属性出现内部错误
补救措施 : 将字段切换为记录或对象 使用具有内联修饰符的方法，将产生类似的性能
svn公司 : 40656 例子 ：以下代码现在失败：
单元 测试 ;
{$模式objfpc}
接口
类型
T测试1 = 班
字段 : 字符串 ;
结束 ;
T测试2 = 班
私有的
f测试1 : T测试1 ;
公众的
财产 道具 : 字符串 阅读 f测试1 . 字段 ; //错误“需要记录或对象类型”
结束 ;
实施
结束 .
Delphi模式下枚举常数的范围检查
陈旧的行为 ：超出范围的枚举常量在Delphi模式中从未导致错误，因为早期版本的Delphi也没有。 新行为 ：在Delphi模式下，即使禁用范围检查，超出范围的枚举常量也会导致错误。 当前的Delphi版本（甚至更早的版本，如Delphi 7）行为相同。 原因 ：Delphi-兼容性。 补救措施 ：修复范围错误。 svn公司 : 42272, 42275
语言更改
泛型类型参数的可见性
陈旧的行为 ：泛型的类型参数具有 公众的 可见性。 新行为 ：泛型的类型参数现在有 严格保密 可见性。 原因 ：使用以前的可见性，可以创建在编译过程中导致无限循环或其他难以调试的错误的代码。 此外，不可能解决这个问题（有关示例，请参阅 这 错误报告）。 此外，修复程序与Delphi兼容。 补救措施 ：为具有所需可见性的类型参数声明类型别名。 例子 ：在以下示例中 T型 声明为 严格保密 ，同时 塔利亚斯 声明为 公众的 因此可以像更改之前一样使用。
类型
通用的 T测试 < T型 > = 班
公众的 类型
塔利亚斯 = T型 ;
结束 ;
正在分析的 专门从事 已更改
陈旧的行为 : 专门从事 用于初始化专门化，后跟可能包含单元名和父类型的类型名。 新行为 : 专门从事 现在被认为是特殊类型的一部分，就像 通用的 这意味着需要在包含 专门从事 . 原因 ：这允许更合理地使用 专门从事 在嵌套类型（尤其是涉及多个专门化的情况下）以及更重要的泛型函数和方法的上下文中。 补救措施 ：将 专门从事 直接在需要专门化的类型前面。
操作员过载 + 不再允许用于动态数组
陈旧的行为 ：该 + 对于动态数组类型，运算符可能被重载。 新行为 ：该 + 如果模式切换，则无法再重载动态数组类型的运算符 数组运算符 处于活动状态（Delphi模式中的默认值）。 原因 ：模式切换时 数组运算符 处于活动状态 + 运算符现在由编译器本身提供，它将两个数组连接在一起。 补救措施 : 禁用模式开关（对于Delphi模式，可以使用 {$modeswitch数组运算符-} ). 如果您的操作符只连接了两个数组，则删除重载。 如果操作员执行了不同或更多操作，请使用不同的操作员。
注释 ：如果重载在范围内，但由于内部运算符的原因而未使用，编译器将发出警告。
泛型类型参数需要匹配
陈旧的行为 ：在定义泛型类或记录的方法时，可以为类型参数使用与声明中使用的名称不同的名称。 新行为 ：方法定义中类或记录类型的泛型类型参数的顺序和名称必须与类或记录声明中泛型类型的参数顺序和名称匹配。 原因 ：避免用户出错，例如当参数的顺序被调换时。 此外，这至少与更新的Delphi版本兼容。 补救措施 ：对定义使用正确的泛型类型参数。 svn公司 : 39701
实现接口方法的方法的可见性
陈旧的行为 ：在寻找实现接口的方法时，考虑了类层次结构中的所有方法 新行为 ：只考虑声明为实现方法的类中可见的方法。 原因 ：在所有情况下都应遵守符号可见性规则。 此修复程序与Delphi兼容。 补救措施 ：使（严格）私有方法在受保护的子类或公共子类中实现接口方法。 svn公司 : 40645
实现接口方法和重载的方法
陈旧的行为 ：在寻找实现接口的方法时，考虑了类层次结构中的所有方法。 新行为 ：在重载的情况下，当找到具有正确名称但没有 超载 指令。 请注意，重写方法时会自动继承此指令。 原因 ：调用方法时也会发生同样的情况，并且符号解析规则在所有情况下都应该相同。 此修复程序与Delphi兼容。 补救措施 ：添加 超载 指向所有重载都应在整个类层次结构中可见的方法的指令。 例子 : svn公司 : 40683
目标C“相关结果类型”
陈旧的行为 ：类型检查系统总是在Objective-C方法返回声明的结果类型时评估对它们的调用。 新行为 ：类型检查系统现在考虑 “相关结果类型” 这意味着现在假设某些方法总是返回一个实例，该实例的类型与消息发送到的对象兼容（即，它是相同的，或者继承自它）。 如果以下方法的声明结果类型也与声明该方法的类类型兼容，则对这些方法执行此操作： 消息名称中第一个小写单词为 初始化 或 新的 消息名称中第一个小写单词为的类方法 自动释放 , 初始化 , 保持 ，或 自己
原因 ：与最新版本的Cocoa标头的翻译兼容 补救措施 ：通常这不会破坏现有的正确代码。 如果是这样，您可能可以通过删除多余的类型转换来修复它。 例子 :
{$模式objfpc}
{$modeswitch对象1}
类型
FPCMy类型 = 对象类
功能 初始化 : 身份证件 ; 消息 “初始化” ;
班 功能 分配 : FPCMy类型 ; 消息 “initWithValue” ;
//由于ObjCBool与FPCMyType无关，因此此处不适用“相关结果类型”规则
//即使消息以“retain”开头并且是一个类方法
班 功能 保留计数 : 对象CBool ; 消息 '保留计数' ;
结束 ;
...
无功功率，无功功率
一 : 不可变数组 ;
开始
//即使FPCMyType返回“id”，也会给出错误，因为“id”与
//FPCMyType，因此编译器现在将“init”消息解释为返回
//调用时显示“FPCMyType”。 请注意，“init”的实际返回类型仍然是
//所有其他上下文中的“id”，例如在决定覆盖兼容性时。 宣言
//没有修改该方法的，唯一改变的是调用它时
//结果类型被静态假定为FPCMyType。
一 := FPCMy类型 . 分配 . 初始化 ;
结束 ;
svn公司 ：r42816
RTTI变更
接口的RTTI（已发布属性计数）
旧行为 ：接口（COM和Corba）的属性RTTI数据紧跟在TTypeData记录之后，没有任何计数。 新行为 ：在属性RTTI之前，数据现在是一个字计数字段，用于指定属性的数量 原因 ：用户请求和可用性。 补救措施 ：相应地调整访问特性数据的指针偏移。
COM接口的RTTI（IID字符串）
旧行为 ：COM接口在设备名称IntfUnit和属性数据之间包含未记录的IIDStr。 新行为 ：已删除未记录字段。 原因 ：COM接口的IID始终可以表示为GUID，因此未记录的IIDStr字段是多余的。 补救措施 ：使用GUID字段并将其转换为字符串。
RTTI二进制格式更改
旧行为 ：对其他类型的引用由PTypeInfo指定。 新行为 ：其他类型的引用由PPTypeInfo指定。 原因 ：虽然二进制格式的更改与Delphi兼容，但原因是引入了对动态包的支持以及需要播放的PE文件格式（Windows）规则。 补救措施 ：如果您不直接访问二进制数据，则不需要进行任何更改。 否则，您需要添加进一步的去芬太尼。 注释 : 如果没有引用，PPTypeInfo值本身将为零，而不是存储在其中的PTypeInfo引用。 这不适用于TObject。 仍返回PTypeInfo的ClassInfo
Corba接口的RTTI（IID字符串）
旧行为 ：IIDStr是TTypeData的字段。 新行为 ：IIDStr是TTypeData的属性。 原因 ：编译器假定IIDStr前面的RawIntfUnit字段是长度为255的ShortString，尽管相应的二进制数据只有它所包含的字符串的长度，因此访问的数据不正确。 补救措施 ：如果只访问了数据，则不会发生任何更改，但IIDStr后面的数据需要以不同的方式访问，因为RawIntfUnit是最后一个可见字段。 svn公司 : 35026
记录初始信息参考
旧行为 ：字段RecSize紧跟在TTypeData记录开始之后。 新行为 ：字段RecSize前面是指针字段RecInitInfo，它指向记录init信息的TTypeInfo（后面是TRecInitData）。 原因 ：使用记录初始化信息，可以更快地决定记录是否需要分类为 管理 对于Rtti单元的IsManaged（）功能来说，这是非常有用的。 补救措施 ：如果您依赖于RecSize在TTypeData中的相对位置，则需要调整代码。 注释 ：TRecInitData与记录的TTypeData共享其前三个字段，不同之处在于指向init信息的指针为零。 svn公司 : 35125, 35134
TOrdType扩展
旧行为 ：TOrdType包含8、16和32位宽度的条目。 新行为 ：TOrdType包含8位、16位、32位和64位宽度的条目。 原因 ：如果不扩展TOrdType，则无法正确表示64位宽度的布尔类型，因为对于Pascal Boolean类型，它们无法与最小值为0、最大值为1的普通整数进行区分，而对于Windows Boolean型，最小值为-1，最大值为0。 补救措施 ：调整将TOrdType作为索引的数组。 svn公司 : 35135
tkInt64和tkQWord的新OrdType字段
旧行为 ：MinInt64Value和MinQWordValue紧跟在TTypeData记录开始后。 新行为 ：MinInt64Value和MinQWordValue前面有一个OrdType字段，该字段将它们分别明确指定为otSQWord或otUQword。 原因 ：为了正确表示64位布尔值，TTypeData的tkInt64和tkQWord分支必须成为tkInteger（又称Ordinal）分支的一部分，因此它们获得了OrdType字段。 补救措施 ：如果代码依赖于MinInt64Value和MinQWordValue相对于TTypeData记录开头的相对位置，则需要进行调整。 svn公司 : 35135
TProcedureParam的第一个字段已更改
旧行为 ：TProcedureParam的第一个字段称为Flags，类型为Byte。 新行为 ：TProcedureParam的第一个字段称为ParamFlags，类型为TParamFlag，有一个名为Flags的属性，类型为Byte。 原因 ：由于TParamFlags是一个集合，如果向TParamFlag中添加更多值，它可能会超过Byte的大小。 补救措施 ：大多数代码应该能够使用向后且与Delphi兼容的Flags属性（至少如果它只想检查序号小于8的TParamFlag值），其他代码应该切换到使用ParamFlags。 svn公司 : 35174
TParamFlag扩展用于constref
旧行为 ：TParamFlag没有用于constref参数的条目。 新行为 ：TParamFlag具有constref参数的条目pfConstRef。 原因 ：要正确检测结构参数，需要相应地标记它们。 补救措施 ：根据TParamFlag中包含的元素数量调整代码（例如，case-statements或数组索引）。 svn公司 : 35175
调整的布尔类型范围
旧行为 ：ByteBool、WordBool和LongBool的范围为0..-1。 新行为 ：ByteBool、WordBool和LongBool的范围为Low（LongInt）到High（LongInt）。 原因 ：旧行为只是剪切用作布尔类型范围的Low（Int64）和High（Int64）值，这是错误的。 范围不取决于大小，这与Delphi兼容。 补救措施 ：调整可能依赖于范围的代码 无效 . svn公司 : 35184
Boolean64和QWordBool的OrdType已调整
旧行为 ：Boolean64具有OrdType otUByte，QWordBool具有OrdTypeotSByte，其范围为MinValue和MaxValue。 新行为 ：Boolean64具有OrdType otUQWord，范围为MinQWordValue和MaxQWordValue，QWordBool具有OrdType otSQWord，范围为MinInt64Value和MaxInt64Value。 原因 ：这两种类型的大小都是64位，因此使用较小的大小是不正确的。 补救措施 ：使用正确的字段检索类型的范围边界。 svn公司 : 35185
所有布尔类型都具有TypeKind tkBool
旧行为 ：Boolean具有TypeKind tkBool，而其他Boolean类型（Boolean16、Boolean32、Boolean 64、ByteBool、WordBool、LongBool、QWordBoo1）具有TypeKind-tkInteger。 新行为 ：Boolean、Boolean16、Boolean 32、BooleanC4、ByteBool、WordBool、LongBool和QWordBoo1具有TypeKind tkBool。 原因 ：将普通子范围与实际布尔类型区分开来的一致性和可能性。 补救措施 ：检查TypeKind tkBool，而不是一些“魔术”来检测布尔类型。 注释 ：由于字段在记录中只能出现一次，因此未调整TTypeData的tkBool分支。 然而，这并没有实际后果，因为变量记录的所有字段总是可以访问的。 svn公司 : 35186, 35187
旧行为 ：TParamFlag没有函数的隐藏参数（Array High、Self、Vmt、Result）的条目； SizeOf（TParamFlags）=1 新行为 ：TParamFlag的条目pfHidden用于隐藏参数，pfHigh用于开放数组的高参数，pfSelf用于实例或类类型，pfVmt用于构造函数的VMT参数，如果结果作为参数传递，则为pfResult； SizeOf（TParamFlags）=2 原因 ：由于计划对Invoke（）使用基于管理器的方法，RTL粘合代码应尽可能少地了解调用约定； 因此，需要知道隐藏参数的位置。 补救措施 ：调整依赖于TParamFlag中包含的元素数量的代码（例如case-statements或数组索引），以及依赖于TParamFlags大小为1的代码（应改用SizeOf（TParamFlags））。 svn公司 : 35267, 35286, 35291
旧行为 ：方法指针变量的参数仅列出了可见参数。 新行为 ：方法指针变量的参数列出了所有参数。 原因 ：使函数调用管理器的实现更加稳定，以防ABI发生变化。 补救措施 ：根据您的代码，处理新参数或检查 pf隐藏 并忽略它们。 svn公司 : 39885
旧行为 ：过程变量的参数仅列出了可见参数。 新行为 ：过程变量的参数列出了所有参数。 原因 ：使函数调用管理器的实现更加稳定，以防ABI发生变化。 补救措施 ：根据代码处理新参数或检查 pf隐藏 并忽略它们。 svn公司 : 39885
实数、指针和字符串属性的隐式默认值
旧行为 ：Real、指针和字符串属性没有隐式值。 默认情况下存储零值和空字符串。 新行为 ：Real、pointer和string属性的隐式默认值分别为0或``。 因此，默认情况下不再存储这些值。 原因 : 1. Delphi兼容性。 2 违约 修饰符不能用于这些属性-在FPC 3.0.x中无法设置0或“”默认值。 补救措施 ：该 无默认值 必须将修饰符添加到属性声明中。 更多详细信息 ：检查 文档 了解更多信息。 还有更多关于字符串存储处理的修复。 svn公司 : 37954
单位变动
系统实用程序
faSymlink公司
旧行为： faSymlink的数值是40美元。 这在windows上是错误的，与Delphi不兼容。 新行为： faSymlink的数值为400美元。 在窗口上进行更正。 变更原因： 错误的功能和Delphi兼容性。 补救措施： 如果您使用的是旧的数值常量$40，只需使用faSymlink即可。 svn： 33340兰特
文件存在于基于Unix的系统上
旧行为： 否存在 收益 真的 用于现有目录。 新行为： 否存在 不返回 真的 用于现有目录。 变更原因： 目录不是文件，因此对于 否存在 返回 真的 用于现有目录。 这也使它与Windows和Delphi保持一致。 补救措施： 使用 目录存在 检查目录是否存在 svn： r43111号
课程。 TList自动增长
旧行为： 元素数大于127的列表扩展了当前容量的1/4 新行为： 添加两个新阈值。 如果元素数大于128 MB，则列表将按16 MB元素的常量展开（相当于128 MB的1/8）。 如果元素数大于8MB，则列表将扩展其当前容量的1/8。 变更原因： 扩展超大列表时避免内存不足 svn： 34462
数学最小值/最大值
旧行为： 由于没有QWord过载，因此可以混合QWord和Int64。 然而，结果可能是错误的。 新行为： QWord的重载现在存在，但与Int64/QWord的混合调用会导致编译器错误。 变更原因： Delphi兼容性。 补救措施： 对其中一个参数应用显式类型转换，使两者具有相同的类型。 svn： 39995
StrUtils Ansi开始文本/Ansi结束文本
旧行为： 对于空子字符串，AnsiStartsText或AnsiEndsText将返回false。这与Delphi不一致，Delphi返回true。 新行为： AnsiStartsText或AnsiEndsText现在为空子字符串返回True。 变更原因： Delphi兼容性。 补救措施： 如果您依赖旧行为，请显式检查空字符串。 svn： 38768
类型IStream接口和类TStreamAdapter
旧行为： IStream接口（类单元和jwa单元）将Int64用于各种输出参数。 新行为： IStream接口（类单元和jwa单元）将QWord用于各种输出参数。 变更原因： MS头使用largeUint，它可以翻译成QWord。 标题是一个旧版本的Delphi，它不知道QWord。 补救措施： 如果实现此接口的类不再编译，则调整接口方法的签名，使其符合新定义。 svn： 32820和35542
Baseunix（仅限Linux）
旧行为： stat是一个并集，一边是正确的posix字段名，另一边是不推荐使用的简化的1.0.x字段名。 1.0.x已被标记为2个主要周期的弃用版本。 新行为： 删除了不推荐的1.0.x字段名。 变更原因： 左侧1.0.x过渡功能。 与其他*nix端口不兼容。 补救措施： 更新字段名 svn： 39644和39655
类T字符串。 LoadFromStream/File编码处理
旧行为： LoadFromStream调用完全忽略了文件的编码，从流中加载文件时不考虑编码，除非指定了编码。 新行为： 存在一个带有布尔参数“IgnoreEncoding”的重载调用，该参数决定是否应考虑编码。 默认情况下，此参数为False，这意味着LoadFromStream现在只使用一个stream作为参数来调用LoadFrom流的编码软件版本，并将编码传递给它Nil，这意味着将使用默认编码。 变更原因： Delphi兼容性，以及TStringStream构造函数中的相应更改。 补救措施： 通过将IgnoreEncoding参数设置为“True”，可以恢复旧行为。 svn： 37962和37965
TStringStream现在观察系统编码
陈旧的行为 ：TStringStream按原样从构造函数中指定的字符串中复制字节。 新行为 ：现在使用字符串编码从字符串中提取字节。 原因： Delphi-兼容性 补救措施： 将具有正确编码的字符串传递给TStringStream svn公司 : 36758
TStringStream派生自TBytesStream
陈旧的行为 : T字符串流 源自TStream。 新行为 : T字符串流 派生自 TBytesStream公司 这反过来又源于 TMemoryStream（内存流） . 原因： 上述观察系统编码所需的 Delphi-兼容性
补救措施： 您需要调整继承检查。 svn公司 : 36758
数据库
陈旧的行为 ：TFileStream。 使用了Create（FileName，fmOpenRead），它阻止了对同一文件的后续访问（也是只读的） 新行为 ：TFileStream。 使用Create（FileName，fmOpenRead+fmShareDenyWrite），这不会阻止对同一文件的读取访问 补救措施 ：如果应用程序需要独占访问文件，请指定fmShareExclusive
支持CodePage的TStringField和TMemoField
陈旧的行为 ：这些字符字段与它们提供的数据无关。 当我们使用AsString数据读取此类字段的内容时，IOW从内部字符缓冲区按原样传递到字符串，而没有进行任何转换。 新行为 ：创建这些字段时，可以指定CodePage（如果假定没有指定CP_ACP），它定义了此字段显示的字符数据的编码。 如果是sqlDB TSQLConnection。 通常使用CharSet。 当我们使用AsString读取此类字段的内容时，字符数据从字段代码页转换为CP_ACP。 当我们使用AsUTF8String（转换为CP_UTF8）或AsUnicodeString（翻译为UTF-16）读取内容时，也会发生相同的转换。 此更改反映了FPC3中引入的CodePage感知字符串。
Unix平台上的ODBC标头默认为3.52版本
陈旧的行为 ：默认值为ODBCVER$0351。 SQLLEN/SQLULEN在64位Unix平台上是32位的。 新行为 ：默认值为ODBCVER$0352。 SQLLEN/SQLULEN在64位Unix平台上是64位的。 因此，它会影响一些ODBCAPI函数，这些函数使用这种类型的参数（当然，它也会影响TODBCConnection）。 另外，安装的unixODBC/iODBC包必须与此匹配（如果是unixODBC，可以使用“odbcinst-j”SQLLEN/SQLULEN在64位平台上必须是8个字节）。
TBlobData不透明类型被重写为TB
陈旧的行为 ：TBlobData已声明为Ansistring 新行为 ：TBlobData声明为TB字节 变更原因 ：Delphi兼容性。 还有助于避免可能的代码页记录。 补救措施 ：如果应用程序使用TBlobData作为字符串，则可以使用AsString作为参数，或转换为TBytes。
FGL公司
TTypeList类型的声明已更改
旧行为 ：类型 T类型列表 泛型类的 TFPG列表 , TFPG对象列表 和 TFPG接口对象列表 声明为 T的数组[0..GMaxListSize] . 新行为 ：类型 T类型列表 泛型类的 TFPG列表 , TFPG对象列表 和 TFPG接口对象列表 声明为 PT公司 . 原因 ：方式 G最大列表大小 已声明，这可能会导致静态数组类型过大，因此使用 数据段太大 错误。 如果启用了范围检查，这也可能会导致不正确的范围错误。由于FPC支持对指针类型的索引访问，因此在使用 列表 属性应该是最小的。 补救措施 ：如果您的应用程序依赖于 PTypeList（类型列表） 要成为静态数组类型（而不仅仅是像数组那样可以索引），则需要调整代码。 svn公司 : 39464
对象数据库
陈旧的行为 ：Objective-C BOOL类型由objcbase表示。 BOOL，它与所有平台上的Pascal布尔值相同。 新行为 ：Objective-C BOOL类型现在由objcbase表示。 ObjCBOOL，它映射到始终与Objective-C中使用的布尔类型相对应的布尔类型（在某些平台上有所不同） 原因 ：重命名是为了防止名称冲突，类型定义的更改是为了解决Objective-Pascal和Objective-C之间的接口问题 补救措施 ：将Objective-Pascal方法定义中Boolean和BOOL的所有用法更改为ObjCBool。 svn公司 : 42483
简单IPC
陈旧的行为 ：ReadMessage是一个过程。 新行为 ：ReadMessage是一个函数，返回一个布尔值，告诉您消息是否已被实际读取。 原因 ：向用户提供更多信息。 补救措施 ：必要时处理结果。 （如果使用OnMessage，则无需更改） svn公司 : 36916
工艺装置
运行命令
旧行为： 当被调用进程长时间运行时，RunCommand有几个短睡眠以减少CPU使用。 新行为： 除非将poRunIdle传递给带有进程选项的默认参数，否则RunCommand默认为无睡眠。 变更原因： 运行二进制文件以快速获取信息的应用程序由于无缘无故的暂停而暂停。 由于管道读取中的操作系统行为略有不同，在不提供额外信息的情况下充分维护短时间和长时间运行的二进制文件似乎是不可能的。 补救措施： 对于快速启动的短期流程：什么都不做。 对于长时间运行的进程，将poRunIdle作为进程选项传递。 svn： 这些更改是在RC1之后合并的
Windows上的poNoConsole
旧行为： 在Windows上，poNoConsole映射到Win-API DETACH_PROCESS，后者仍创建标准输入/输出/错误句柄。 新行为： poNoConsole映射到CREATE_NO_WINDOW，它不会创建输入/输出/错误句柄。 新选项poDetached允许DETACH_PROCESS。 变更原因： poNoConsole仍然在案例中创建了一个窗口。 （螳螂 错误32055 ). 补救措施： 如果您试图隐藏控制台，但仍然需要stdin/stdout句柄，那么poNoConsole将不再工作。 你可以试试poDetached。 另请参见 podetached论坛线程 svn： poDetached选项是在RC1之后创建的
fpHTTPClient和fpHTTPServer单元
旧行为： 旧设备使用OpenSSL内置了对SSL的支持。 新行为： 程序在执行HTTPS请求时返回错误“No SSL Socket support compiled in”。 变更原因： 支持SSL的可插拔体系结构。 补救措施： 添加一个单位 开放sslsockets （OpenSSL）或 gnutls插槽 （GNU TLS）到程序的uses子句。
Linux/Android平台
默认情况下需要GNU Binutils 2.19.1或更高版本
陈旧的行为 ：编译器对链接器的调用总是导致一条警告，指出“您忘记了-T吗？” 新行为 ：编译器现在使用不同的方式来调用链接器，这可以防止出现此警告，但这需要仅在GNU Binutils 2.19及更高版本中可用的功能。 原因 ：删除链接器警告，这是由于我们以不受支持的方式使用链接器（因此偶尔会导致问题）。 补救措施 ：如果您的系统具有较旧版本的GNU Binutils，则可以使用新的 -X9系列 命令行参数使编译器还原为旧行为。 不过，您将无法（轻松）在这样的系统上引导新版本的FPC，因此请使用另一个具有更新版本GNU Binutils的系统。
Linux/i386上的堆栈对齐
陈旧的行为 ：Linux/i386的堆栈对齐为4个字节。 新行为 ：Linux/i386的堆栈对齐为16字节。 原因 ：与当前Linux/i386 ABI和其他Linux/i38.6编译器生成的代码兼容。 补救措施 ：此更改通常只影响调用子例程的内联汇编代码。 如果您有这样的代码，请确保在调用任何子例程之前将堆栈对齐为16字节的倍数。 如果例程返回后使用被调用方移除任何堆栈参数的调用约定，则可能还必须将堆栈重新对齐为16个字节。
i386平台
这个 帕斯卡 调用约定现在遵循32位x86平台上的Delphi约定
陈旧的行为 ：编译器始终使用 帕斯卡 调用约定，甚至对于纯汇编例程也是如此。 新行为 ：编译器现在在新的i8086（16位x86）目标上只有旧的行为。 在其他目标上，它只保存/恢复 电子束等离子体 / 径向基功率 注册。 原因 ：在16位x86上，我们遵循Turbo Pascal行为（它还保存了所有这些寄存器），在其他x86平台上，我们遵守Delphi行为。 补救措施 ：如果是使用 帕斯卡 调用约定（通常是除 EAX公司 , ECX公司 和 EDX公司 ). 评论 在64位x86-64平台上 帕斯卡 不支持调用约定，并映射到ABI定义的默认调用约定。
-Ooasmcse/{$optimization asmcse}已删除
陈旧的行为 ：编译器包含用于i386平台的汇编程序通用子表达式消除传递。 新行为 ：此优化过程已从编译器中删除。 原因 ：由于没有维护该传递，该传递在几次发布后默认被禁用，并且在与更新的优化传递结合时生成了错误代码。 补救措施 ：不再使用-Ooasmcse/{$optimization asmcse}。
i8086平台
在小型和紧凑型内存模型中，代码指针类型已更改
陈旧的行为 ：编译器使用NearPointer类型获取小型紧凑内存模型中的过程、函数和标签的地址。 新行为 ：编译器现在使用NearCsPointer类型获取小型紧凑内存模型中的过程、函数和标签的地址。 原因 ：使用NearCsPointer更准确地表示代码位于小内存模型中的单独段中，并且还允许读取过程的机器代码，这在低级代码中可能很有用。 补救措施 ：如果您的程序使用小内存模型并且需要任何修复，那么很可能会出现编译时类型检查错误，因为指针和代码指针类型不再兼容。 要解决这些问题，请将所有指向代码的指针更改为CodePointer，而不是Pointer。 或者，如果您的程序非常小（代码+数据<=64k），您可以切换到微型内存模型，其中指针和CodePointer类型仍然兼容。 如果您的程序使用紧凑型内存模型，则不太可能出现任何类型的破坏，因为指针和代码指针类型在该内存模型中已经不兼容。 svn公司 : 38691
达尔文/macOS平台
默认目标macOS版本
陈旧的行为 ：i386（Intel 32位）平台的默认目标版本是Mac OS X 10.4（Tiger），x86-64（Intel 64位）的默认目标版是Mac OS X10.5（Leopard）。 新行为 ：i386（Intel 32位）和x86-64（Intel 64位）平台的默认目标版本现在是OS X 10.8（Mountain Lion）。 原因 ：在macOS 10.14上，安装命令行工具时，不再将目标为较旧目标时所需的crt*.o文件放置在与以前相同的位置，因此需要自定义命令行选项和对fpc.cfg的修改。 补救措施 ：如果您希望针对那些早期的操作系统版本，请使用 -WM10.4标准 相应的。 -WM10.5型 编译器的命令行参数，并在必要时将其指向仍包含对具有 -XR/path/to/SDK 参数（如有必要，还可以指向支持已删除架构的汇编程序/链接器 -FD/path/to/clang_and_ld ). svn公司 : 43374
Darwin/i386和被调用方删除堆栈参数的调用约定
陈旧的行为 ：Darwin/i386代码生成器将所有调用约定视为“调用者删除堆栈参数”，即使对于通常情况下不是这样的调用约定也是如此。 新行为 ：Darwin/i386代码生成器正确处理被调用方删除堆栈参数的调用约定。 特别是，这改变了 登记 , 调用约定 , 安全呼叫 、和 帕斯卡语 调用约定。 原因 ：尊重调用约定，与其他平台和编译器兼容。 补救措施 ：如果您有内联汇编代码处理Darwin/i386在旧的FPC版本下的这种特殊行为，您可以在FPC 3.2及更高版本中禁用它。 达尔文/i386现在按照与 Linux/i386 . svn公司 ：r43650
Windows平台
默认情况下需要GNU Binutils 2.25或更高版本
陈旧的行为 ：如果一个单元的二进制文件包含太多的段（>$7fff），则编译失败，因为二进制格式不支持那么多的段。 新行为 ：如果一个单元的二进制文件包含多个部分（>$7fff），它将使用COFF的BigObj格式进行编译。 原因 ：一些单位（例如。 包\odata\src\sharepoint.pp )变得如此之大，以至于无法再使用正常的COFF格式进行编译。 内部汇编程序和链接器可以像GNU binutils一样处理这种格式，但只能从2.25开始。 补救措施 ：如果您使用binutils进行编译，而不是使用内部汇编程序/链接器，则可以使用最新版本的binutils（>=2.25），或者如果您确实需要使用旧版本，则传递-a5，这将禁用BigObj COFF文件的使用， 尽管你将无法构建整个FPC分发，也无法链接到如此大的单元。
