You need to provide a complete runnable example, the sniplet you provided is missing all the interesting parts.
On Tuesday, 2 February 2021 at 3:58:39 pm UTC+8 Robert M. Münch wrote: > > Here we go: https://pastebin.com/6c6rq92K > > The code to access the C lib was generated with c-for-go, so there is a > lot of house-keeping stuff going on. However, I don't think this has any > influence on the C code data. > > I implemented getCHeight (see commented lines 155ff, to access the C data > as direct as possible. The functions prints the output as in my previous > post. > Ian Lance Taylor schrieb am Dienstag, 2. Februar 2021 um 00:58:01 UTC+1: > >> On Mon, Feb 1, 2021 at 1:52 PM Robert M. Münch >> <robert...@saphirion.com> wrote: >> > >> > I know all about the problems of FP comparison, and yes I know that I >> need to provide more information. What makes me suspicious is, that I have >> a bunch of equivalent tests before the failing one, and all pass. I still >> believe in the determinism of programs. Hence, this is all really strange. >> > >> > I run the C test code (without any Go) in GDB and the values are >> correctly set. This is how the data looks before the call, setting the >> correct values: >> > >> > 804 YGNodeCalculateLayout(root, YGUndefined, YGUndefined, >> YGDirectionLTR); >> > (gdb) p root.layout_.dimensions >> > $9 = { >> > _M_elems = {nan(0x400000), nan(0x400000)} >> > } >> > >> > and this is after the call: >> > >> > (gdb) p root.layout_.dimensions >> > $13 = { >> > _M_elems = {320, 10} >> > } >> > >> > I write a C wrapper function, that outputs the return value just before >> it's returned and makes its way through the Go FFI. Here is the output >> before the call: >> > >> > YGNodeLayoutGetWidth: 1.#QNAN0 7FC00000 >> > YGNodeLayoutGetHeight: 1.#QNAN0 7FC00000 >> > >> > and after the call >> > >> > YGNodeLayoutGetWidth: 320.000000 43A00000 >> > YGNodeLayoutGetHeight: 1000000020040877300000.000000 6258D727 >> > >> > So, why are the values before the call are different in C and the C >> side within the Go program? I mean why once 0x400000 and 0x7FC00000? I >> would have expected that the C code behaves the same. >> > And as you can see the 320 is set in both cases, but the expected 10 is >> a totally screwed up floating-point value. >> > >> > Could this be an alignment problem? Does CGO add some wrapping code, >> which does some strange things? >> > >> > Unfortunately, I didn't find a way, how I can enter the C code from a >> debugger when using the Go binary. Looks like there is no C debug >> information available. >> >> cgo adds multiple wrapping functions. >> >> I don't know what the problem is here. I can imagine several >> different possibilities. Show us the code, and we won't have to >> guess. Thanks. >> >> Ian >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/d0c2a315-66b3-479d-b537-f5bdbe624cefn%40googlegroups.com.
