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/1f195471-d43c-4512-91f4-a820b45c1257n%40googlegroups.com.
