c - 原始 C 和 Fortran 类型的最终长度

标签 c compiler-construction 64-bit fortran

我目前正在将 32/64 位上所有主要操作系统的 BLAS/LAPACK(Fortran 库)的 native 绑定(bind)修改为 Java 库:netlib-java .

但是,我开始遇到一些与 UNIX/Windows 世界之间以及 Fortran/C 之间的数据类型差异有关的问题。

Fortran 的表和 C数据类型非常不明确,因为大小 are not explicitly defined by the C language .

是否有关于 Fortran 和 C 的主要操作系统上原始数据类型的所有位大小的规范来源(或者我们可以通过引用权威来源创建一个?)

或者,至少,C 类型方面的 Fortran 类型。

即用以下列填充表格(开始时先列几列):

OS      ARCH    Language Type             Bits
Linux   x86_64  C        int              32
Linux   x86_64  C        long             64
Linux   x86_64  C        float            32
Linux   x86_64  C        double           64
Linux   x86_64  Fortran  LOGICAL          32
Linux   x86_64  Fortran  INTEGER          32
Linux   x86_64  Fortran  REAL             32
Linux   x86_64  Fortran  DOUBLE PRECISION 64
Linux   x86_64  Java JNI jint             32
Windows x86_64  Fortran  INTEGER          32
Windows x86_64  Java JNI jint             64
...

(我不确定这是否正确)

可以在每个 JDK 附带的 jni_md.h 中根据 C 原语查找 Java 类型。

最佳答案

正如@cup 在评论中指出的那样,有一个 ISO_C_BINDING标准。这给了我们一定程度的安慰(至少对于 GCC),CBLAS/LAPACKE C API(使用基本 C 类型)中提到的映射可以使用该编译器跨体系结构移植。正如问题中所指出的,这是关于位大小在实践中,而不是语言保证什么的抽象概念。即

  • REAL -> float
  • double -> double
  • INTEGER -> int
  • 逻辑 -> int

然后由 C 定义原始类型的字节大小,由 jni_md.h 定义 Java 原始类型。

在实践中,这意味着唯一的断开是在 64 位 Windows 上 long 是 32 位(在 64 位 Linux 上是 64 位)和 jint 是根据 long 定义的。因此 compiler complains about jint*/int type conversions在 Windows 构建期间可以安全地忽略。

关于c - 原始 C 和 Fortran 类型的最终长度,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/18162198/

相关文章:

c - 如何找到我当前的编译器标准,比如它是 C90 等

dll - 在64位机器上使用32位dll

visual-studio-2015 - gacutil.exe 在 Windows 10 中的什么位置?

c - 用C程序杀死一个进程

字符数组打印比我在 C 中想要的更多

c - 如何使用指针将值读入结构?

compiler-construction - 为什么 Wasm GC 设计要解决类型相等性、标记、子类型和方法等问题?

c - 关于int *a={1,2,3}的有效性。为什么随后的 *a 会崩溃?

parsing - 左递归语法中先发现后跟随的混淆

.net - 如何确定 System.Diagnostics.Process 是 32 位还是 64 位?