Thanks for the reply.
On 2018-01-07 19:39, taylanbayi...@gmail.com wrote:
Amirouche Boubekki <amirou...@hypermove.net> writes:
Here are some possibilities I can think of, wildly speculatively.
- %time-relative is defined wrong (I couldn't find the corresponding
GNUNET_TIME_Relative definition to compare)
Here is the definition in C of GNUNET_TIME_Relative:
struct GNUNET_TIME_Relative
{
uint64_t rel_value_us;
};
Here is the definition in Guile:
(define %time-relative (bs:struct `((rel-value-us ,uint64))))
- %crypto-ecdsa-public-key is defined wrong (I couldn't find the
corresponding GNUNET_CRYPTO_EcdsaPublicKey definition to compare)
Here is the definition in C:
struct GNUNET_CRYPTO_EcdsaPublicKey
{
unsigned char q_y[256 / 8];
};
Here is the definition in Guile:
(define %crypto-ecdsa-public-key (bs:struct `((q-y ,(bs:vector (/ 256 8)
uint8)))))
If both of those are correct, further possibilities would be:
- Some or all of the structs in the C code are "packed".
- There's a bug in bytestructures.
To rule out these two, you can use a simple test case: write a tiny C
lib with a function that allocates a GNUNET_FS_ProgressInfo struct,
writes to its status field, and returns a pointer to it. Load the lib
from Scheme, call the function through FFI... you know the rest; see if
you get the correct value when you read the status field from Scheme.
I get the wrong result.
FWIW, you can reproduce following those steps:
$ git clone git://gnunet.org/gnunet-guile2.git
$ cd gnunet-guile2
$ guix package -f guix.scm
$ ./bootstrap && ./configure
$ c99
-I/gnu/store/nfaljkxhj0hgxkzxbd4pgmm70h9niq7q-gnunet-git-0.10.1-2.477e0de/include/gnunet/
-c example.c -o libexample.o && gcc -shared libexample.o -o
libexample.so
$ ./pre-inst-env guile example.scm
The expected output is 42.