Thankyou kddavidson772. Although it's not critical for this particular
test, I will add that to this test and another very similar to it that
operates slightly differently. I have put the same seed code you suggest in
other routines but other folks wrote the initial versions of this
particular
Ian,
Did you (or anybody else reading this) have any other thoughts on what I
can try since GODEBUG="cgocheck=2" did not show anything? Nor (in summary)
has -msan, -race or the memory sanity debugging built into our C code.
We're kinda stuck at this point.
Steve
--
You received this message
Since those C functions are already returning a return code through the
return value and C only has one return, that's not really possible. I could
allocate 4 bytes of C memory, pass the address to that, make the call,
return the value and free the memory - and I will do that if we get to the
p
Thankyou Ian,
I did try a few runs with GODEBUG set to "cgocheck=2" and just the "normal"
errors (bad Go heap ptr, and sweep increased allocation) occurred. I'm
assuming I would have seen a different kind of panic if it had detected
something.
Like I mentioned in the last post, we are very car
YottaDB is a key-value NoSQL databaase with a C API. To make it more
friendly to Golang users, we have created a Go wrapper (see
https://godoc.org/lang.yottadb.com/go/yottadb). A Rust wrapper is in
development, with other languages to follow.
With the Golang wrapper, we have run into a varie
