为什么我无法正确读取Golang的C常量？ [英] Why can't I read a C constant from Golang properly?

问题描述

我使用go-hdf5将hdf5文件读入golang。我在windows7上使用了mingw和hdf5 1.8.14_x86的最新版本，看起来好像试图使用任何预定义的类型都不起作用，所以我们将重点放在T_NATIVE_UINT64上。我已经将问题简化为以下内容，这基本上使go-hdf5免于问题，并指出了一些根本性的错误：

  package main 
 
 / * 
 #cgo CFLAGS：-IC：/HDF_Group/HDF5/1.8.14_x86/include 
 #cgo LDFLAGS：-LC：/ HDF_Group / HDF5 /1.8.14_x86/bin -lhdf5 -lhdf5_hl 
 #includehdf5.h
 
 #include< stdio.h> 
 
 void print_the_value2（）{printf（常量的值是％d \ n，H5T_NATIVE_UINT64）; } 
 * / 
 importC
 
 func main（）{
 C.print_the_value2（）
} 
  
 
 $ b 
你显然需要hdf5并将编译器指向headers / dlls并运行go get，然后执行在我的pc上打印 p> 
 
 
 常数值为-1962924545 
  
运行上述变体，读取常量的方式/位置将给出H5T_NATIVE_UINT64值的不同答案。不过，我很确定没有一个是正确的价值，实际上试图使用返回的id的类型不起作用，这并不令人惊讶。 
 
 
 
如果我编写并运行一个真正的C程序，我会得到不同的结果 
 
 
  #include< stdio.h> 
 #includehdf5.h
 
 hid_t _go_hdf5_H5T_NATIVE_UINT64（）{return H5T_NATIVE_UINT64; } 
 $ b $ int main（）
 {
 printf（常量的值是％d，_go_hdf5_H5T_NATIVE_UINT64（））; 
 
 $ / code> 
编译使用
  C：\ Temp> gcc -IC：/HDF_Group/HDF5/1.8.14_x86/include -LC：/HDF_Group/HDF5/1.8.14_x86/bin -lhdf5 -lhdf5_hl -o stuff .exe stuff.c 
  
并且正在运行给我 
 
 
 常数值为50331683 
  
似乎是正确的价值，因为我可以直接从我的go程序中使用它。很明显，我想能够使用常量代替。任何想法，为什么会发生这种情况？ 
 
 
 
以下评论的额外信息：
 
 
 
我在hdf5头文件中查找了H5T_NATIVE_UINT64的定义，以下
  c：\HDF_Group\HDF5\1.8.14_x86\include> grep H5T_NATIVE_UINT64 * 
 H5Tpkg .h：H5_DLLVAR size_t H5T_NATIVE_UINT64_ALIGN_g; 
 H5Tpublic.h：#define H5T_NATIVE_UINT64（H5OPEN H5T_NATIVE_UINT64_g）
 H5Tpublic.h：H5_DLLVAR hid_t H5T_NATIVE_UINT64_g; 
  
整个标题在这里 
 
 
 < a href =http://www.hdfgroup.org/ftp/HDF5/prev-releases/hdf5-1.8.14/src/unpacked/src/H5Tpublic.h =noreferrer> http：// www。 hdfgroup.org/ftp/HDF5/prev-releases/hdf5-1.8.14/src/unpacked/src/H5Tpublic.h  
 
 
 
谢谢！ H5T_NATIVE_UINT64不是一个常量，而是一个#define，最终计算结果为（H5Open（），H5T_NATIVE_UINT64_g）
 
 
解决方案
 / code>，这是cgo不理解的。
 
 
 
通过打开gcc预处理器的调试输出可以很容易地检查：
 
 
  gcc -E -dM your_test_c_file.c | grep H5T_NATIVE_UINT64 
  
结果： 
 
 
  #define H5T_NATIVE_UINT64（H5OPEN H5T_NATIVE_UINT64_g）
  
现在H5OPEN也一样：
  gcc -E -dM test_go.c | grep'#define H5OPEN'
  
给出：
 
 < pre $  #define H5OPEN H5open（），
  

现在， cgo明白简单的整数常量定义如 #define VALUE 1234 ，或者任何gcc预处理器将变成一个整数常量。在 $ GOROOT / src / cmd / cgo / gcc.go 中查看 func（p * Package）guessKinds（f * File）函数C $ C>。


I am using go-hdf5 to read an hdf5 file into golang. I am on windows7 using a pretty recent copy of mingw and hdf5 1.8.14_x86 and it seems like trying to use any of the predefined types doesn't work, let's focus for example on T_NATIVE_UINT64. I have reduced the issue to the following, which basically leaves go-hdf5 out of the problem and points at something quite fundamental going wrong:

package main

/*
 #cgo CFLAGS: -IC:/HDF_Group/HDF5/1.8.14_x86/include
 #cgo LDFLAGS: -LC:/HDF_Group/HDF5/1.8.14_x86/bin -lhdf5 -lhdf5_hl
 #include "hdf5.h"

 #include <stdio.h>

 void print_the_value2() { printf("the value of the constant is %d\n", H5T_NATIVE_UINT64); }
*/
import "C"

func main() {
    C.print_the_value2()
}

You obviously need to have hdf5 and point the compiler at the headers/dlls and running go get, then executing prints this on my pc

the value of the constant is -1962924545

Running variations of the above, in how/where the constant is read, will give different answers for the value of H5T_NATIVE_UINT64. However I am pretty sure that is none are the right value and in fact trying to use a type with the id returned doesn't work, unsurprisingly.

If I write and run a "real" C program, I get different results

#include <stdio.h>
#include "hdf5.h"

hid_t _go_hdf5_H5T_NATIVE_UINT64() { return H5T_NATIVE_UINT64; }

int main()
{
    printf("the value of the constant is %d", _go_hdf5_H5T_NATIVE_UINT64());
}

Compiling using

C:\Temp>gcc -IC:/HDF_Group/HDF5/1.8.14_x86/include -LC:/HDF_Group/HDF5/1.8.14_x86/bin -lhdf5 -lhdf5_hl -o stuff.exe stuff.c

and running gives me

the value of the constant is 50331683

And that appears to be the right value as I can use it directly from my go program. Obviously I want to be able to use the constants instead. Any idea why this could be happening?

Extra info following comments below:

I looked for the definition of H5T_NATIVE_UINT64 in the hdf5 headers and see the following

c:\HDF_Group\HDF5\1.8.14_x86\include>grep H5T_NATIVE_UINT64 *
H5Tpkg.h:H5_DLLVAR size_t H5T_NATIVE_UINT64_ALIGN_g; 
H5Tpublic.h:#define H5T_NATIVE_UINT64 (H5OPEN H5T_NATIVE_UINT64_g)
H5Tpublic.h:H5_DLLVAR hid_t H5T_NATIVE_UINT64_g;

The whole header is here

http://www.hdfgroup.org/ftp/HDF5/prev-releases/hdf5-1.8.14/src/unpacked/src/H5Tpublic.h

Thanks!

解决方案

H5T_NATIVE_UINT64 is NOT a constant but a #define that ultimately evaluates to (H5Open(), H5T_NATIVE_UINT64_g), which cgo does not understand.

It's easy to check by turning on debug output on gcc's preprocessor:

gcc -E -dM your_test_c_file.c | grep H5T_NATIVE_UINT64

Result:

#define H5T_NATIVE_UINT64 (H5OPEN H5T_NATIVE_UINT64_g)

Now the same for H5OPEN:

gcc -E -dM test_go.c | grep '#define H5OPEN'

gives:

#define H5OPEN H5open(),

Right now, cgo does understand simple integer constant defines like #define VALUE 1234, or anything that the gcc preprocessor will turn into an integer constant. See the function func (p *Package) guessKinds(f *File) in $GOROOT/src/cmd/cgo/gcc.go.

这篇关于为什么我无法正确读取Golang的C常量？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！