应该在API中使用枚举吗? [英] Should enum never be used in an API?

查看:152
本文介绍了应该在API中使用枚举吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在使用一个提供给我已经编译的C库。编译库时使用的编译器,版本,选项等信息有限。图书馆界面在传递的结构中直接使用枚举



问题是:我可以确定或确定当我编译代码以使用提供的库时,我的编译器将对那些枚举使用相同的大小?如果没有,结构将不会排队,并且参数传递可能被弄乱,例如。 long vs. int



我的关注源于C99标准指出,枚举类型:


应与char,有符号整数类型或无符号
整数类型。类型的选择是实现定义的,但是
能够表示
枚举的所有成员的值。


据我所知,只要最大的值适合,编译器可以选择任何类型,它很好地喜欢,有效的一个奇怪的,可能不仅在编译器之间变化,但不同版本的相同编译器和/或编译器选项。它可以选择1,2,4或8字节表示,导致结构和参数传递中的潜在的不兼容性。 (它也可以选择签名或未签名,但我没有看到在这种情况下是一个问题的机制。)



我在这里遗漏了什么?如果我没有错过任何东西,这是否意味着不要在API中使用枚举



更新:



是的,我错过了一些东西。虽然语言规范在这里没有帮助,如@Barmar所述,应用程序二进制接口(ABI)。或者如果没有,则ABI是不足的。 我的系统的ABI 确实指定了一个枚举必须是一个有符号的四字节整数。如果一个编译器不服从,那就是一个bug。给定一个完整的ABI和兼容的编译器,可以在API中安全地使用枚举

解决方案

使用枚举的API取决于编译器将是一致的假设,即给定相同的枚举声明,它将始终选择相同的底层类型。



虽然语言标准并没有特别要求这一点,但编译器做任何其他操作都是相当不利的。



此外,特定操作系统的所有编译器都必须与操作系统的ABI一致。否则,你会有更多的问题,例如库使用64位 int ,而调用者使用32位 int 。理想情况下,ABI应限制枚举的表示,以确保兼容性。



更一般地,语言规范仅确保使用相同实现编译的程序之间的兼容性。 ABI确保了使用不同实现编译的程序之间的兼容性。


I am using a C library provided to me already compiled. I have limited information on the compiler, version, options, etc., used when compiling the library. The library interface uses enum both in structures that are passed and directly as passed parameters.

The question is: how can I assure or establish that when I compile code to use the provided library, that my compiler will use the same size for those enums? If it does not, the structures won't line up, and the parameter passing may be messed up, e.g. long vs. int.

My concern stems from the C99 standard, which states that the enum type:

shall be compatible with char, a signed integer type, or an unsigned integer type. The choice of type is implementation-defined, but shall be capable of representing the values of all the members of the enumeration.

As far as I can tell, so long as the largest value fits, the compiler can pick any type it darn well pleases, effectively on a whim, potentially varying not only between compilers, but different versions of the same compiler and/or compiler options. It could pick 1, 2, 4, or 8-byte representations, resulting in potential incompatibilities in both structures and parameter passing. (It could also pick signed or unsigned, but I don't see a mechanism for that being a problem in this context.)

Am I missing something here? If I am not missing something, does this mean that enum should never be used in an API?

Update:

Yes, I was missing something. While the language specification doesn't help here, as noted by @Barmar the Application Binary Interface (ABI) does. Or if it doesn't, then the ABI is deficient. The ABI for my system indeed specifies that an enum must be a signed four-byte integer. If a compiler does not obey that, then it is a bug. Given a complete ABI and compliant compilers, enum can be used safely in an API.

解决方案

APIs that use enum are depending on the assumption that the compiler will be consistent, i.e. given the same enum declaration, it will always choose the same underlying type.

While the language standard doesn't specifically require this, it would be quite perverse for a compiler to do anything else.

Furthermore, all compilers for a particular OS need to be consistent with the OS's ABI. Otherwise, you would have far more problems, such as the library using 64-bit int while the caller uses 32-bit int. Ideally, the ABI should constrain the representation of enums, to ensure compatibility.

More generally, the language specification only ensures compatibility between programs compiled with the same implementation. The ABI ensures compatibility between programs compiled with different implementations.

这篇关于应该在API中使用枚举吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆