Enums Gnat编译器升级导致出现与枚举相关的约束_错误

我正在从事一个从另一家公司继承的传统Ada 95项目。我最近将我们的编译器从Gnat 3.13a1升级到Gnat 4.7.4。程序仍在编译，但其中一个任务由于约束错误而崩溃

Process_Ua(Buffer, Msg_Kind);

Tr_Log5("MSG KIND IS: " & Message_Received_Type'Image(Msg_Kind));

---

约束错误发生在上面的第二行，消息为“无效数据”。Msg_Kind的类型为message_Received_type（这是枚举类型），并且在子程序开始时已正确初始化，因此我很难理解数据如何无效，当将非消息类型的任何内容分配给消息类型时，将导致约束错误。

无效数据始终是未初始化变量的符号

我假定您正在使用
-gnatVa
和
pragma Initialize_Scalars
（您已将其放入
gnat.adc
文件或从项目的
生成器全局配置_Pragmas
属性引用的文件中）进行编译

在这种情况下，编译器尝试使用无效值（超出有效范围）初始化变量，并添加其他检查。当检查失败时，会引发
无效\u数据
异常

可能旧的编译器总是在初始化一个
out
参数（但这会令人惊讶，它会如何选择默认值）？
在调用
Tr\u Log5
之前，尝试检查
MsgKind
的值，或者检查
Message\u Received\u Type'Pos（Msg\u Kind）
的值。不确定这是否是正确的方法，但我已经用“Integer”图像（Message\u Received\u Type'Pos（Msg\u Kind））”记录了你所说的话。它正在打印“32”，但消息类型只有6个可能的值。这怎么会发生？这个模块在过去的15年里一直没有改变，只是在新的编译器中出现了这个问题。嗯，你的程序有一个bug吗？可能问题一直存在，而问题被隐藏了起来，因为较旧的编译器未能引发
Constraint\u Error
。那只是我的猜测。您仍然可以访问旧的编译器吗？问题可能是未初始化的数据。您不能指望它有任何特定的值，代码生成方式的更改（例如改进的优化）可能会影响存储在那里的垃圾值。如果它有一个无效的值，语言不会定义Pos对它的作用，因此32是一个可能的结果。@Ogre我不知道什么是
Process\u UA
，但是如果这可以设置
Msg\u Kind
（即
out
或
in-out
参数），问题可能是
Process\u UA
中的一个未初始化变量。“
无效\u数据
始终是未初始化变量的符号。”“总是吗？这可能是由于无效值的
未经检查的\u转换
，或者由于在禁止检查的情况下执行了不安全的操作。是的，也可能是代码中定义的异常。然而，根据我的经验，当使用
-gnatVa
和
初始化\u标量时，它是一个未初始化的变量。