戈朗C长双 [英] C long double in golang

问题描述

我正在将算法从C移植到Go.我有些困惑.这是C函数:

I am porting an algorithm from C to Go. And I got a little bit confused. This is the C function:

void gauss_gen_cdf(uint64_t cdf[], long double sigma, int n)
{
    int i;
    long double s, d, e;

    //Calculations ...

    for (i = 1; i < n - 1; i++) {
       cdf[i] = s;
    }   
}

然后在for循环中，将值s分配给元素cd数组x.这怎么可能?据我所知，长双精度数是float64(在Go上下文中).因此，我不应该编译C代码，因为我正在向只包含uint64元素的数组分配一个long double.但是C代码可以正常工作.

And in the for loop value "s" is assigned to element "x" the array cdf. How is this possible? As far as I know, a long double is a float64 (in the Go context). So I shouldn't be able to compile the C code because I am assigning an long double to an array which just contains uint64 elements. But the C code is working fine.

所以有人可以解释一下为什么这样吗?

So can someone please explain why this is working?

非常感谢您.

更新:

该函数的原始C代码可以在以下位置找到: https://github.com/mjosaarinen/hilabliss/blob/master/distribution.c#L22

The original C code of the function can be found here: https://github.com/mjosaarinen/hilabliss/blob/master/distribution.c#L22

推荐答案

赋值 cdf [i] = s 隐式转换为 uint64_t .没有您省略的计算，很难说出这是否是故意的.

The assignment cdf[i] = s performs an implicit conversion to uint64_t. It's hard to tell if this is intended without the calculations you omitted.

在实践中， long double 作为一种类型在整个体系结构中都有相当大的差异.Go的 float64 是否合适，取决于您要移植的体系结构.例如，在x86上， long double 是80字节的扩展精度类型，但是

In practice, long double as a type has considerable variance across architectures. Whether Go's float64 is an appropriate replacement depends on the architecture you are porting from. For example, on x86, long double is an 80-byte extended precision type, but Windows systems are usually configured in such a way to compute results only with the 53-bit mantissa, which means that float64 could still be equivalent for your purposes.

编辑，在这种情况下，由源计算的值似乎是静态的，并且与输入无关.我只想在Go端使用 float64 ，看看当在真正的GNU/Linux下的x86机器上运行时(虚拟化应该可以)，计算出的值是否与C版本的值相同.解决Windows FPU问题.选择x86只是一个猜测，因为它很可能是原始作者所使用的.我不了解底层的加密技术，因此无法说出计算值的差异是否会影响安全性.(还要注意，C代码似乎无法正确植入其PRNG.)

EDIT In this particular case, the values computed by the sources appear to be static and independent of the input. I would just use float64 on the Go side and see if the computed values are identical to those of the C version, when run on a x86 machine under real GNU/Linux (virtualization should be okay), to work around the Windows FPU issues. The choice of x86 is just a guess because it is likely what the original author used. I do not understand the underlying cryptography, so I can't say whether a difference in the computed values impact the security. (Also note that the C code does not seem to properly seed its PRNG.)

这篇关于戈朗C长双的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！